已经一个多月没有写东西了，不过最近确实很忙。前两天在线上碰到一个C3P0的链接死锁的异常，话说这个上古神物 ,我已经是很久不碰了。先贴异常

"apparent deadlocks"：名词解释是说c3p0拿到链接之后，最终使用之后没有返回到pool,导致死链检测失败。经过在stack Overflow检索,https://stackoverflow.com/questions/3730844/c3p0-apparent-deadlock-when-the-threads-are-all-empty.发现增加一个statementCacheNumDeferredCloseThreads该参数的定义，就可以避免这个问题。

经过查看官方文档：http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads

解释：如果把该值设为超过1，statement的缓存就会自动跟踪当前可用的connections,如果没有再用，就会自动销毁掉。如果需要另外的线程来专门销毁缓存的statement,则还需要设置maxStatements与maxStatementsPerConnection。

再贴一个官方的说明：

Configuring Statement Pooling

c3p0 implements transparent PreparedStatement pooling as defined by the JDBC spec. Under some circumstances, statement pooling can dramatically improve application performance. Under other circumstances, the overhead of statement pooling can slightly harm performance. Whether and how much statement pooling will help depends on how much parsing, planning, and optimizing of queries your databases does when the statements are prepared. Databases (and JDBC drivers) vary widely in this respect. It's a good idea to benchmark your application with and without statement pooling to see if and how much it helps.

You configure statement pooling in c3p0 via the following configuration parameters:

maxStatements

maxStatementsPerConnection

statementCacheNumDeferredCloseThreads

maxStatementsis JDBC's standard parameter for controlling statement pooling.maxStatementsdefines the total numberPreparedStatementsa DataSource will cache. The pool will destroy the least-recently-used PreparedStatement when it hits this limit. This sounds simple, but it's actually a strange approach, because cached statements conceptually belong to individual Connections; they are not global resources. To figure out a size formaxStatementsthat does not "churn" cached statements, you need to consider the number offrequently usedPreparedStatements in your application,and multiply that by the number of Connections you expect in the pool (maxPoolSizein a busy application).

maxStatementsPerConnectionis a non-standard configuration parameter that makes a bit more sense conceptually. It defines how many statements each pooled Connection is allowed to own. You can set this to a bit more than the number ofPreparedStatementsyour applicationfrequentlyuses, to avoid churning.

If either of these parameters are greater than zero, statement pooling will be enabled. If both parameters are greater than zero, both limits will be enforced. If only one is greater than zero, statement pooling will be enabled, but only one limit will be enforced.

大概意思就是这两个，有一个值如果大于0，c3p0的statement pool就会发生作用。

以上所有的配置都是基于c3p0的最新版本。PS一下，还是2015年的JAR。

通过引入最新的C3P0包，另外增加了两段配置，线上观察两天，问题解决。

最后打个小广告，JAVA世界最快的JDBC连接池，非HikariCP莫属。已经甩c3p0好几个街角，有图有真像。

     摘要: 在word的处理之中，文字，各种类型的图片，最复杂的公式，之前编写的API基本都覆盖了。不过，昨天在做一个文档测试时，发现表格没有能很好的处理。  阅读全文      摘要: 作为日常支付业务，微信的接入逐渐进入了大家的视野。今天以PC端接入微信支付的基本流程来说明。  阅读全文      摘要: 在WORD里面编辑公式，目前是有两种方法。  阅读全文      摘要: 当我们淡到RPC服务框架，放眼世界范围，我目前知道的主流有thrift,fingle,grpc等。当然大型互联网公司都会有自己的RPC服务与治理框架。经过一段时间的调研，本着简单，高效的原则,最终选择thrift.具体原因，等接下来写到服务篇的时候再细说。  阅读全文      摘要: 目前公司业务上，有课程直播这一块。为了增加用户的互动，需要增加聊天室功能。聊天室，对实时性有较严格的要求，所以考虑使用socketio来做。目前在服务端，有基于netty实现的websocketio的框架。https://github.com/mrniko/netty-socketio，这个作者还是挺厉害的（redisson的作者）。  阅读全文      摘要: 对于后端的参数校验，我们一直在强调的验证规则，提示信息的重用。这不，springmvc通过集成Valid最大程序减少了我们的工作量。其实后端的参数过滤，是分几种请求来源的。每种的处理都不太一样，但是我们如果能重用验证规则，提示信息，那就很强大了。  阅读全文

      已经一个多月没有写东西了，不过最近确实很忙。前两天在线上碰到一个C3P0的链接死锁的异常，话说这个上古神物 ,我已经是很久不碰了。先贴异常

"apparent deadlocks"：名词解释是说c3p0拿到链接之后，最终使用之后没有返回到pool,导致死链检测失败。经过在stack Overflow检索,https://stackoverflow.com/questions/3730844/c3p0-apparent-deadlock-when-the-threads-are-all-empty.发现增加一个statementCacheNumDeferredCloseThreads该参数的定义，就可以避免这个问题。

经过查看官方文档：http://www.mchange.com/projects/c3p0/#statementCacheNumDeferredCloseThreads

解释：如果把该值设为超过1，statement的缓存就会自动跟踪当前可用的connections,如果没有再用，就会自动销毁掉。如果需要另外的线程来专门销毁缓存的statement,则还需要设置maxStatements与maxStatementsPerConnection。

再贴一个官方的说明：

Configuring Statement Pooling

c3p0 implements transparent PreparedStatement pooling as defined by the JDBC spec. Under some circumstances, statement pooling can dramatically improve application performance. Under other circumstances, the overhead of statement pooling can slightly harm performance. Whether and how much statement pooling will help depends on how much parsing, planning, and optimizing of queries your databases does when the statements are prepared. Databases (and JDBC drivers) vary widely in this respect. It's a good idea to benchmark your application with and without statement pooling to see if and how much it helps.

You configure statement pooling in c3p0 via the following configuration parameters:

maxStatements

maxStatementsPerConnection

statementCacheNumDeferredCloseThreads

maxStatementsis JDBC's standard parameter for controlling statement pooling.maxStatementsdefines the total numberPreparedStatementsa DataSource will cache. The pool will destroy the least-recently-used PreparedStatement when it hits this limit. This sounds simple, but it's actually a strange approach, because cached statements conceptually belong to individual Connections; they are not global resources. To figure out a size formaxStatementsthat does not "churn" cached statements, you need to consider the number offrequently usedPreparedStatements in your application,and multiply that by the number of Connections you expect in the pool (maxPoolSizein a busy application).

maxStatementsPerConnectionis a non-standard configuration parameter that makes a bit more sense conceptually. It defines how many statements each pooled Connection is allowed to own. You can set this to a bit more than the number ofPreparedStatementsyour applicationfrequentlyuses, to avoid churning.

If either of these parameters are greater than zero, statement pooling will be enabled. If both parameters are greater than zero, both limits will be enforced. If only one is greater than zero, statement pooling will be enabled, but only one limit will be enforced.

大概意思就是这两个，有一个值如果大于0，c3p0的statement pool就会发生作用。

以上所有的配置都是基于c3p0的最新版本。PS一下，还是2015年的JAR。

通过引入最新的C3P0包，另外增加了两段配置，线上观察两天，问题解决。

最后打个小广告，JAVA世界最快的JDBC连接池，非HikariCP莫属。已经甩c3p0好几个街角，有图有真像。

     摘要: 在word的处理之中，文字，各种类型的图片，最复杂的公式，之前编写的API基本都覆盖了。不过，昨天在做一个文档测试时，发现表格没有能很好的处理。  阅读全文

     摘要: HDFS和MapReduce是Hadoop的两大核心，除此之外Hbase、Hive这两个核心工具也随着Hadoop发展变得越来越重要。今天我们只初步的看看HDFS.  阅读全文

     摘要: 使用thrift已经有段时间了，目前基本是clien+server的方式，负载是通过nginx来处理。这种处理方式有两个比较大的弊端：  阅读全文

    www.taggerin.com，主要处理日常文档的在线编辑，以及与Markdown,PDF,html等格式的双向转换.听说内测版本已经发布。真正的文档在线编辑与预览。

     摘要: 一般的业务开发，不会涉及到多种数据库类型的操作。因为，无论是对于开发，还是运维，成本都是非常高的。如果是ORACLE数据库到MYSQL的数据备份，目前我所了解的开源解决方案有2种：  阅读全文

     摘要: 作为日常支付业务，微信的接入逐渐进入了大家的视野。今天以PC端接入微信支付的基本流程来说明。  阅读全文

     摘要: 在WORD里面编辑公式，目前是有两种方法。  阅读全文

     摘要: 最近在弄项目的压测，首先想到把应用服务器TOMCAT的相关配置升级，网上看了很多关于TOMCAT升级的案例，于是结合自己的实际情况，做了笔记。  阅读全文

     摘要: 当我们淡到RPC服务框架，放眼世界范围，我目前知道的主流有thrift,fingle,grpc等。当然大型互联网公司都会有自己的RPC服务与治理框架。经过一段时间的调研，本着简单，高效的原则,最终选择thrift.具体原因，等接下来写到服务篇的时候再细说。  阅读全文