已经一个多月没有写东西了，不过最近确实很忙。前两天在线上碰到一个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.具体原因，等接下来写到服务篇的时候再细说。  阅读全文      摘要: 目前公司业务上，有课程直播这一块。为了增加用户的互动，需要增加聊天室功能。聊天室，对实时性有较严格的要求，所以考虑使用socketio来做。目前在服务端，有基于netty实现的websocketio的框架。https://github.com/mrniko/netty-socketio，这个作者还是挺厉害的（redisson的作者）。  阅读全文      摘要: SOLR作为成熟的企业级检索服务，已经有些年头。我在5年前，也接触部分皮毛。当时跟另外一个同事，一起学习学运用到我们的产品之中，当时是面对的数据量是500-700百W，多表联合处理。然后通过SOLR，引入索引，再走日常的查询。大概也是在4年前，在入门MVN之后，通过MVN快速搭建了SOLR运行环境，几天前，又翻看了一下写的POM,觉得很有必要与大家进行一下REVIEW，温故而知新！我也对比了当前网上多如牛毛的SOLR搭建文章，总感觉我照着做，还是不会。当然，当时的POM，我是参照了国外一个大牛弄的，当时的SOLR版本是4.4.0.目前SOLR的6版本都出来，不过，需要JDK8以上。鄙人一直在用JDK7,所以，不考虑一下跨那么大，怕扯到蛋了。哈哈，玩笑话。另外由于之前分词，是用的jcseg,当时的版本也比较旧（1.8.9），所以今天做了相关升级。我就分享一下相关的心得，多有不足，欢迎指正。

环境说明：  阅读全文      摘要: 本文不涉及太多配置项管理，只是针对小白用户的最快安装手册  阅读全文      摘要: 在当前的互联网类产品中，如何高效可用的生成的一个全局自增ID，是一个比较有挑战性的工作。我见过的一般的做法其实就是时间戳再加固定长度的随机 字符串。这个方案其实有两个问题，一个是生成的自增ID的可读性，另外就是随机，并不是真正的唯一，它是一个碰撞概率的。其它方案，如依赖数据的自增 ID，如果多个库，可以通过不同的步长来实现可读的序列。不过，这其实性能上肯定不可能很高。另外，会有单点的问题。所以，果断放弃。在查看了目前比较成 熟的snowfake方案之后，感觉不错。下图是它的算法核心  阅读全文      摘要: 最近在调研文件的分布式存储及高可用，在GITHUB上面，发现了这个SeaweedFS项目不错。  阅读全文      摘要: 今天在一个技术群里面，有同学提到了HyperLogLog（数据结构），排序方面技术。所以今天看一下相关的资料，算作一个总结。  阅读全文      摘要: docx4j是一款在java世界处理微软word/ppt/excel文档的强大工具。它其实是一个半开源的产品。虽然它对WORD各种处理在API层 面进行了封装，但是像WORD本身的拆分，合并。其作者（Jason Harrop）是单独提出来了，封装成了商用的JAR包来提供支持。而我在深入学习其API之后，先后将组合，拆分技术进行了实现。  阅读全文