已經一個多月沒有寫東西了，不過最近確實很忙。前兩天在線上碰到一個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最大程序減少了我們的工作量。其實后端的參數過濾，是分幾種請求來源的。每種的處理都不太一樣，但是我們如果能重用驗證規則，提示信息，那就很強大了。  閱讀全文