c3p0引數解釋

#最常用配置
#initialPoolSize：連線池初始化時建立的連線數,default : 3，取值應在minPoolSize與maxPoolSize之間
c3p0.initialPoolSize=10
#minPoolSize：連線池保持的最小連線數,default : 3
c3p0.minPoolSize=10
#maxPoolSize：連線池中擁有的最大連線數，如果獲得新連線時會使連線總數超過這個值則不會再獲取新連線，而是等待其他連線釋放，所以這個值有可能會設計地很大,default : 15
c3p0.maxPoolSize=50
#acquireIncrement：連線池在無空閒連線可用時一次性建立的新資料庫連線數,default : 3
c3p0.acquireIncrement=5
#管理連線池的大小和連線的生存時間
#maxIdleTime：

連線的最大空閒時間，如果超過這個時間，某個資料庫連線還沒有被使用，則會斷開掉這個連線。如果為0，則永遠不會斷開連線,即回收此連線。default : 0 單位 s建議：不能設定太短，否則連線會被頻繁的丟棄。
c3p0.maxIdleTime=600
#idleConnectionTestPeriod：每900秒檢查所有連線池中的空閒連線
c3p0.idleConnectionTestPeriod=900
#重連相關配置 
#acquireRetryAttempts：連線池在獲得新連線失敗時重試的次數，如果小於等於0則無限重試直至連接獲得成功。default : 30（建議使用）
c3p0.acquireRetryAttempts=5
#acquireRetryDelay：兩次連線中間隔時間，單位毫秒，連線池在獲得新連線時的間隔時間。default : 1000 單位ms（建議使用）
c3p0.acquireRetryDelay=1000
#breakAfterAcquireFailure：如果為true，則當連接獲取失敗時自動關閉資料來源，除非重新啟動應用程式。所以一般不用。default : false（不建議使用）
c3p0.breakAfterAcquireFailure=false
#checkoutTimeout：配置當連線池所有連線用完時應用程式getConnection的等待時間。為0則無限等待直至有其他連線釋放或者建立新的連線，單位毫秒。不為0則當時間到的時候如果仍沒有獲得連線，則會丟擲SQLException。其實就是acquireRetryAttempts*acquireRetryDelay。default : 0（與上面兩個，有重複，選擇其中兩個都行）
c3p0.checkoutTimeout=100
#其他
#autoCommitOnClose：連線池在回收資料庫連線時是否自動提交事務。如果為false，則會回滾未提交的事務，如果為true，則會自動提交事務。default : false（不建議使用）
c3p0.autoCommitOnClose=false
#c3p0是非同步操作的，緩慢的JDBC操作通過幫助程序完成。擴充套件這些操作可以有效的提升效能 通過多執行緒實現多個操作同時被執行。Default: 3
c3p0.numHelperThreads=10

最近專案中用的C3P0連線池出現各種bug，現在記錄一下。

1、經常報連線池死鎖

2016-08-31 15:24:00 [ WARN] - [com.mchange.v2.async.ThreadPoolAsynchronousRunner|run] - com[email protected]74a7d985 -- APPARENT DEADLOCK!!! Complete Status: 
    ⇒  	Managed Threads: 3
    ⇒  	Active Threads: 3
    ⇒  	Active Tasks: 
    ⇒  	co[email protected]115721ba (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2)
    ⇒  	[email protected]f67433a (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0)
    ⇒  	co[email protected]646ecdf9 (com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1)
    ⇒  	Pending Tasks: 
    ⇒  	com.mchange.[email protected]2694c9f2
    ⇒  	[email protected]25642a7
    ⇒  	com.mcha[email protected]7d321c95
    ⇒  	com.mcha[email protected]64f2ba69
    ⇒  Pool thread stack traces:
    ⇒  	Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#2,5,main]
    ⇒  	com.mysql.jdbc.ResultSetImpl.realClose(ResultSetImpl.java:7337)
    ⇒  	com.mysql.jdbc.ResultSetImpl.close(ResultSetImpl.java:922)
    ⇒  	com.mysql.jdbc.StatementImpl.realClose(StatementImpl.java:2528)
    ⇒  	com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3036)
    ⇒  	com.mysql.jdbc.StatementImpl.close(StatementImpl.java:577)
    ⇒  	com.mchange.v1.db.sql.StatementUtils.attemptClose(StatementUtils.java:41)
    ⇒  	com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StatementCloseTask.run(GooGooStatementCache.java:404)
    ⇒  	com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
    ⇒  	Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#0,5,main]
    ⇒  	com.mysql.jdbc.PreparedStatement.initializeFromParseInfo(PreparedStatement.java:2944)
    ⇒  	com.mysql.jdbc.PreparedStatement.<init>(PreparedStatement.java:926)
    ⇒  	com.mysql.jdbc.JDBC4PreparedStatement.<init>(JDBC4PreparedStatement.java:47)
    ⇒  	sun.reflect.GeneratedConstructorAccessor63.newInstance(Unknown Source)
    ⇒  	sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    ⇒  	java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    ⇒  	com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
    ⇒  	com.mysql.jdbc.PreparedStatement.getInstance(PreparedStatement.java:842)
    ⇒  	com.mysql.jdbc.ConnectionImpl.clientPrepareStatement(ConnectionImpl.java:1588)
    ⇒  	com.mysql.jdbc.ConnectionImpl.prepareStatement(ConnectionImpl.java:4604)
    ⇒  	com.mysql.jdbc.ConnectionImpl.prepareStatement(ConnectionImpl.java:4502)
    ⇒  	com.mysql.jdbc.LoadBalancedMySQLConnection.prepareStatement(LoadBalancedMySQLConnection.java:2207)
    ⇒  	sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
    ⇒  	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    ⇒  	java.lang.reflect.Method.invoke(Method.java:606)
    ⇒  	com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:651)
    ⇒  	com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:556)
    ⇒  	com.sun.proxy.$Proxy52.prepareStatement(Unknown Source)
    ⇒  	com.mysql.jdbc.ReplicationConnection.prepareStatement(ReplicationConnection.java:637)
    ⇒  	com.mysql.fabric.jdbc.FabricMySQLConnectionProxy.prepareStatement(FabricMySQLConnectionProxy.java:766)
    ⇒  	sun.reflect.GeneratedMethodAccessor45.invoke(Unknown Source)
    ⇒  	sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    ⇒  	java.lang.reflect.Method.invoke(Method.java:606)
    ⇒  	com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StmtAcquireTask.run(GooGooStatementCache.java:525)
    ⇒  	com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)
    ⇒  	Thread[com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1,5,main]
    ⇒  	com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3021)
    ⇒  	com.mysql.jdbc.StatementImpl.close(StatementImpl.java:577)
    ⇒  	com.mchange.v1.db.sql.StatementUtils.attemptClose(StatementUtils.java:41)
    ⇒  	com.mchange.v2.c3p0.stmt.GooGooStatementCache$1StatementCloseTask.run(GooGooStatementCache.java:404)
    ⇒  	com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547)

使用第二種最新版本的包：

<dependency>
    <groupId>com.mchange</groupId>
    <artifactId>c3p0</artifactId>
    <version>0.9.5.2</version>
</dependency>

這種資料庫連線池執行緒死鎖的問題發生的原因可能有很多，我將我的配置環境以及解決方法貼出來供大家參考一下：

使用環境，spring + c3p0

esp.c3p0.url=${esp.c3p0.url}
esp.c3p0.user=${esp.c3p0.user}
esp.c3p0.password=${esp.c3p0.password}

esp_question.c3p0.url=${esp_question.c3p0.url}
esp_question.c3p0.user=${esp_question.c3p0.user}
esp_question.c3p0.password=${esp_question.c3p0.password}

report.c3p0.url=${report.c3p0.url}
report.c3p0.user=${report.c3p0.user}
report.c3p0.password=${report.c3p0.password}

c3p0.driverClass=com.mysql.fabric.jdbc.FabricMySQLDriver
c3p0.initialPoolSize=5
c3p0.maxPoolSize=50
c3p0.minPoolSize=3

c3p0.maxStatements=0
c3p0.maxStatementsPerConnection=0
c3p0.checkoutTimeout=100

c3p0.acquireIncrement=5
c3p0.acquireRetryDelay=1000
c3p0.acquireRetryAttempts=50
##create connect 
c3p0.autoCommitOnClose=false
c3p0.breakAfterAcquireFailure=false

修改後，我開啟一個多執行緒任務，沒有出現異常。

一般設定maxStatements=0和maxStatementsPerConnection=0解決該問題，但是c3p0在同時關閉statement和connection的時候，或者關閉他們之間的時間很短的時候，有時候connection並沒有被關閉，因為有些preparedstatement還在被cached住。（作者說的http://forum.hibernate.org/viewtopic.php?t=947246&highlight=apparent+deadlock+c3p0）

我在這裡設定checkoutTimeout。（後面還是沒有解決問題）

maxStatements：JDBC的標準引數，用以控制資料來源內載入的PreparedStatements數量。但由於預快取的statements 屬於單個connection而不是整個連線池。所以設定這個引數需要考慮到多方面的因素。Default: 0

maxStatementsPerConnection：連線池為資料來源單個Connection快取的PreparedStatement數，這個配置比maxStatements更有意義，因為它快取的服務物件是單個數據連線，如果設定的好，肯定是可以提高效能的。為0的時候不快取。Default: 0

如果maxStatements與maxStatementsPerConnection均為0，則快取被關閉。只要有一個不為0，則語句的快取就能生效。

c3p0.maxStatements=0
c3p0.maxStatementsPerConnection=0

<!--連線池用完時客戶呼叫getConnection()後等待獲取連線的時間，單位：毫秒。超時後會丟擲-->
 <!--SQLEXCEPTION，如果設定0，則無限等待。Default:0-->
c3p0.checkoutTimeout=100

列印正確日誌：

2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 開始執行
2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 開始執行，time_section: 2015-09-02T20:33:16+08:00 - 2015-10-24T15:42:36+08:00
2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 開始執行
2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 17:20:00 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 開始執行，time_section: 2015-10-24T15:42:36+08:00 - 2015-12-15T10:51:57+08:00
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 開始執行，time_section: 2015-12-15T10:51:57+08:00 - 2016-02-05T06:01:18+08:00
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 開始執行，time_section: 2016-02-05T06:01:18+08:00 - 2016-03-28T01:10:38+08:00
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 17:20:01 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 開始執行，time_section: 2016-03-28T01:10:38+08:00 - 2016-05-18T20:19:59+08:00
2016-08-31 17:20:41 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 處理一次分頁耗時：39 秒
2016-08-31 17:20:41 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復-(2016-02-05T06:01:18+08:00 - 2016-03-28T01:10:38+08:00) 執行完成，共耗時39秒
2016-08-31 17:20:41 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 17:20:41 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - lcNDResourceRepairJob 成功執行完成
2016-08-31 17:20:41 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 執行完成
2016-08-31 17:21:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 處理一次分頁耗時：98 秒
2016-08-31 17:21:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復-(2015-12-15T10:51:57+08:00 - 2016-02-05T06:01:18+08:00) 執行完成，共耗時98秒
2016-08-31 17:21:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 17:21:39 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - lcNDResourceRepairJob 成功執行完成
2016-08-31 17:21:39 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 執行完成
2016-08-31 17:22:13 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 處理一次分頁耗時：131 秒
2016-08-31 17:22:13 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復-(2016-03-28T01:10:38+08:00 - 2016-05-18T20:19:59+08:00) 執行完成，共耗時131秒
2016-08-31 17:22:13 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 17:22:13 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - lcNDResourceRepairJob 成功執行完成
2016-08-31 17:22:13 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 執行完成
2016-08-31 17:23:53 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 處理一次分頁耗時：232 秒
2016-08-31 17:23:53 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復-(2015-09-02T20:33:16+08:00 - 2015-10-24T15:42:36+08:00) 執行完成，共耗時232秒
2016-08-31 17:23:53 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 17:23:53 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - lcNDResourceRepairJob 成功執行完成
2016-08-31 17:23:53 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 執行完成
2016-08-31 17:27:24 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復 處理一次分頁耗時：443 秒
2016-08-31 17:27:24 [ INFO] - [nd.sdp.lcreporting.schedule.job.esp2middle.RPBaseRepairJob|doJob] - 中間庫-資源修復-(2015-10-24T15:42:36+08:00 - 2015-12-15T10:51:57+08:00) 執行完成，共耗時443秒
2016-08-31 17:27:24 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 17:27:24 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - lcNDResourceRepairJob 成功執行完成
2016-08-31 17:27:24 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - esp_to_middle_repair 執行完成

補充：後面又出了問題，是因為quartz裡面沒有配置資料來源資訊，而且quartz用的資料來源和我們自己應用中的資料來源還不一致，所以做了一些配置上的修改:

1）檢視quartz用的什麼資料來源

2）修改pom.xml檔案，排除衝突

3）修改quartz.properties配置，增加以下配置

後面在開發環境、測試環境、預生產環境就再也沒有出現死鎖的情況了。

2、換了一組多執行緒任務進行

{
    "schedule_name" : "middle_to_mongodb_sync",
    "schedule_desc":"中間庫同步到mongodb",
    "time_section_start_time":1463456657382,
    "time_section_end_time":1463732172026,
       "jobs" : [ 
        {
            "name" : "rpDimensionCodesTreeRefreshJob",
            "sort_order" : 1,
            "retry_times" : 3
        },
        {
            "name" : "rpNDResourceSyncJob",
            "sort_order" : 2,
            "retry_times" : 3
        },
        {
            "name" : "rpResourceCategorySyncJob",
            "sort_order" : 3,
            "retry_times" : 3
        },
        {
            "name" : "rpResourceUsageSyncJob",
            "sort_order" : 4,
            "retry_times" : 3
        },
        {
            "name" : "rpResourcesUsageJob",
            "sort_order" : 5,
            "retry_times" : 3
        },
        {
            "name" : "rpResourcesTrendJob",
            "sort_order" : 5,
            "retry_times" : 3
        },
        {
            "name" : "rpResourceRelationTransformJob",
            "sort_order" : 5,
            "retry_times" : 3
        },
        {
            "name" : "rpDimensionCodeStatJob",
            "sort_order" : 5,
            "retry_times" : 3
        },
        {
            "name" : "rpResourceUsagePercentJob",
            "sort_order" : 6,
            "retry_times" : 3
        }

    ]
}

這次又有異常出現，如下：

2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - 中間庫同步到mongodb 開始執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|doInvoke] - 等待前置任務完成
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPDimensionCodesTreeRefreshJob|doJob] - 重新整理DimensionCodesTreeCache
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPDimensionCodesTreeRefreshJob|doJob] - 重新整理成功，共耗時 0:00:00.233 
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - rpDimensionCodesTreeRefreshJob 成功執行完成
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|doInvoke] - 前置任務完成，繼續執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|doInvoke] - 等待前置任務完成
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPNDResourceSyncJob|fetchFromMiddleRepoAndPersist] - 開始同步rpNDResourceSyncJob_1463456657382_1463732172026資料,範圍：1463456657382 - 1463732172026
2016-08-31 19:36:38 [ INFO] - [org.springframework.beans.factory.xml.XmlBeanDefinitionReader|loadBeanDefinitions] - Loading XML bean definitions from class path resource [org/springframework/jdbc/support/sql-error-codes.xml]
2016-08-31 19:36:38 [ INFO] - [org.springframework.jdbc.support.SQLErrorCodesFactory|<init>] - SQLErrorCodes loaded: [DB2, Derby, H2, HSQL, Informix, MS-SQL, MySQL, Oracle, PostgreSQL, Sybase]
2016-08-31 19:36:38 [ERROR] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - JobExecution run rpNDResourceSyncJob 發生錯誤
org.springframework.dao.RecoverableDataAccessException: PreparedStatementCallback; SQL [SELECT identifier, title, description, estatus, enable, primary_category, create_time, last_update  FROM ndresource WHERE last_update BETWEEN ? AND ?  ORDER BY last_update ASC  LIMIT ? OFFSET ?]; Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.
    at org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:98)
    at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
    at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:660)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:695)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:722)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:772)
    at org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate.query(NamedParameterJdbcTemplate.java:192)
    at org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate.query(NamedParameterJdbcTemplate.java:199)
    at nd.sdp.lcreporting.sync.rp.repository.RPNDResourceRepository.findByLastUpdateBetweenOrderByLastUpdateAsc(RPNDResourceRepository.java:56)
    at nd.sdp.lcreporting.schedule.job.middle2mongo.RPNDResourceSyncJob.fetchFromMiddleRepoAndPersist(RPNDResourceSyncJob.java:55)
    at nd.sdp.lcreporting.schedule.job.middle2mongo.RPNDResourceSyncJob.doJob(RPNDResourceSyncJob.java:44)
    at nd.sdp.lcreporting.schedule.job.Job.run(Job.java:159)
    at nd.sdp.lcreporting.schedule.job.JobExecution.run(JobExecution.java:55)
    at nd.sdp.lcreporting.schedule.QuartzJobExecutor$Worker.run(QuartzJobExecutor.java:96)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1127)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3715)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3604)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4155)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2615)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2843)
    at com.mysql.jdbc.LoadBalancedMySQLConnection.execSQL(LoadBalancedMySQLConnection.java:166)
    at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:651)
    at com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:556)
    at com.sun.proxy.$Proxy65.execSQL(Unknown Source)
    at com.mysql.fabric.jdbc.FabricMySQLConnectionProxy.execSQL(FabricMySQLConnectionProxy.java:985)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2085)
    at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2215)
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:353)
    at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:703)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:644)
    ... 14 more
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3161)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3615)
    ... 32 more
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobFailed] - rpNDResourceSyncJob 成功執行失敗
2016-08-31 19:36:38 [ERROR] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|run] - error occurs on worker for rpNDResourceSyncJob
org.springframework.dao.RecoverableDataAccessException: PreparedStatementCallback; SQL [SELECT identifier, title, description, estatus, enable, primary_category, create_time, last_update  FROM ndresource WHERE last_update BETWEEN ? AND ?  ORDER BY last_update ASC  LIMIT ? OFFSET ?]; Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.; nested exception is com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.
    at org.springframework.jdbc.support.SQLExceptionSubclassTranslator.doTranslate(SQLExceptionSubclassTranslator.java:98)
    at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:73)
    at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:81)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:660)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:695)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:722)
    at org.springframework.jdbc.core.JdbcTemplate.query(JdbcTemplate.java:772)
    at org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate.query(NamedParameterJdbcTemplate.java:192)
    at org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate.query(NamedParameterJdbcTemplate.java:199)
    at nd.sdp.lcreporting.sync.rp.repository.RPNDResourceRepository.findByLastUpdateBetweenOrderByLastUpdateAsc(RPNDResourceRepository.java:56)
    at nd.sdp.lcreporting.schedule.job.middle2mongo.RPNDResourceSyncJob.fetchFromMiddleRepoAndPersist(RPNDResourceSyncJob.java:55)
    at nd.sdp.lcreporting.schedule.job.middle2mongo.RPNDResourceSyncJob.doJob(RPNDResourceSyncJob.java:44)
    at nd.sdp.lcreporting.schedule.job.Job.run(Job.java:159)
    at nd.sdp.lcreporting.schedule.job.JobExecution.run(JobExecution.java:55)
    at nd.sdp.lcreporting.schedule.QuartzJobExecutor$Worker.run(QuartzJobExecutor.java:96)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 160,044 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at com.mysql.jdbc.Util.handleNewInstance(Util.java:409)
    at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1127)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3715)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3604)
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4155)
    at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2615)
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2843)
    at com.mysql.jdbc.LoadBalancedMySQLConnection.execSQL(LoadBalancedMySQLConnection.java:166)
    at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:651)
    at com.mysql.jdbc.LoadBalancingConnectionProxy.invoke(LoadBalancingConnectionProxy.java:556)
    at com.sun.proxy.$Proxy65.execSQL(Unknown Source)
    at com.mysql.fabric.jdbc.FabricMySQLConnectionProxy.execSQL(FabricMySQLConnectionProxy.java:985)
    at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2085)
    at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2215)
    at com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeQuery(NewProxyPreparedStatement.java:353)
    at org.springframework.jdbc.core.JdbcTemplate$1.doInPreparedStatement(JdbcTemplate.java:703)
    at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:644)
    ... 14 more
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3161)
    at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3615)
    ... 32 more
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|doInvoke] - 前置任務完成，繼續執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|run] - 任務開始執行
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPResourceCategorySyncJob|fetchFromMiddleRepoAndPersist] - 開始同步rpResourceCategorySyncJob_1463456657382_1463732172026資料,範圍：1463456657382 - 1463732172026
2016-08-31 19:36:38 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|execute] - 中間庫同步到mongodb 執行完成
2016-08-31 19:36:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPResourceCategorySyncJob|persistToMongodb] - 處理一次分頁所用時間：0:00:00.364, 記錄數：92，資源數：20
2016-08-31 19:36:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.middle2mongo.RPResourceCategorySyncJob|fetchFromMiddleRepoAndPersist] - 結束同步 ; jobId :rpResourceCategorySyncJob_1463456657382_1463732172026
2016-08-31 19:36:39 [ INFO] - [nd.sdp.lcreporting.schedule.job.JobExecution|sendNotification] - No message to send
2016-08-31 19:36:39 [ INFO] - [nd.sdp.lcreporting.schedule.QuartzJobExecutor|onJobSuccess] - rpResourceCategorySyncJob 成功執行完成

可以看到上面說的是距上次向伺服器傳送和接收資料已經過了好長時間，所以伺服器自動斷開了連線，這個伺服器不是指web伺服器斷開了瀏覽器的連線，而是指我們的資料庫伺服器斷開了和web容器的連線。這是由於web容器和資料庫伺服器的連線長時間沒有資料（預設是8小時）傳送，所以MySQL自動斷開了連線。一般情況下使用的DBCP、C3P0、Proxool都提供了在分配一個連線時自動測試其是否有效的功能，所以在使用這些時不需要擔心。不過如果是使用的jdbc預設的連線池就會出現這個問題了。URL加上：autoReconnect=true&failOverReadOnly=false。但是最好還是在使用資料庫連線池的情況下，最好設定如下兩個引數：
autoReconnect=true&failOverReadOnly=false

jdbc:mysql://:3306/?autoReconnect=true

解決辦法：

c3p0提供了幾個引數給使用者用於測試連線是否可用。他們分別是automaticTestTable，connectionTesterClassName，idleConnectionTestPeriod，preferredTestQuery，testConnectionOnCheckin， testConnectionOnCheckout。組合使用這幾個引數可以檢測連線是否可用。idleConnectionTestPeriod，testConnectionOnCheckin，testConnectionOnCheckout，這三個引數設定什麼時候檢測連線是否可用，而automaticTestTable，connectionTesterClassName，preferredTestQuery用於設定使用什麼方式檢測連線。

idleConnectionTestPeriod：單位為秒。用來配置測試空閒連線的間隔時間。可以用來解決MySQL8小時斷開連線的問題。因為它保證連線池會每隔一定時間對空閒連線進行一次測試，從而保證有效的空閒連線能每隔一定時間訪問一次資料庫，將於MySQL8小時無會話的狀態打破。為0則不測試。default : 0
testConnectionOnCheckin：布林值，預設為false。如果值為true，在連線放入連線池時會非同步傳送檢測請求到伺服器，檢測連線是否可用。如果為true，則在close（這裡不是真正的關閉）的時候測試連線的有效性。
testConnectionOnCheckout：布林值，預設為false。如果為true，在連線從連線池取出是，會同步發一個檢測請求，以保證連線可用。如果為true，在每次getConnection的時候都會測試，為了提高效能,儘量不要用。

由於testConnectionOnCheckout每個連線使用前都做檢測，這樣會降低效能。如果要滿足高效能的應用中，不建議使用。所以建議組合使用idleConnectionTestPeriod和testConnectionOnCheckin，以保證連線的可用。

automaticTestTable：如果設定了此值，c3p0會自動在資料庫建立一個設定的表，用來檢測連線是否可用。
preferredTestQuery：這個值為用於檢測連線是否可用的查詢語句。在一些資料庫，如MySQL中直接使用"SELECT　１"就可以，不用依賴一個數據庫存在的表。
connectionTesterClassName: 使用者可以自定義一個類來檢測資料庫連線是否可用。

如果是MySQL伺服器，在兼顧效能的方案上，檢測時間使用idleConnectionTestPeriod和testConnectionOnCheckin配置，檢測方式上最簡單的就是"SELECT　１"。參考配置如下：

c3p0.testConnectionOnCheckin=true
c3p0.preferredTestQuery=SELECT 1
c3p0.idleConnectionTestPeriod=10

貌似在這裡已經解決了問題，在本地執行也沒有報過錯，但是最後釋出到公司的開發環境和測試環境還是報這種錯誤，最後檢查了一下發現還需要加一行配置程式碼：

c3p0.maxIdleTime=55（這個值的設定要根據公司MySQL服務端設定的空閒超時斷開時間指定，比如wait_timeout=60s，mysql預設是8小時）maxIdleTime必須要小於wait_timeout（不管這個連線有沒有被close掉，只要這個連線屬於空閒狀態，超過這個時間連線就廢棄）

為什麼要加這行配置程式碼呢？

因為有的資料庫CRUD操作之後，沒有close（不是真正意義上的關閉）掉，只有close後才能迴歸連線池。這裡的close()只是將 資料庫連線池中佔用的connection釋放掉，使其在連線池中處於空閒狀態，如果你不關閉，資料庫連線池中的connection中用完以後，請求就會處於佇列狀態，超出規定時間連線池就會將佇列的請求斷開，導致其無法進行連線。只有close掉，這樣我們才能去心跳校驗，也就是上面那三行程式碼配置才有作用。

spring 中可以使用使用spring 的 DataSourceUtils 裡面有 public static Connection getConnection(DataSource dataSource) throws CannotGetJdbcConnectionException 
和 public static void doReleaseConnection(Connection con, DataSource dataSource) throws SQLException 這兩個是獲得和關閉 連線。

我們用的是spring的jdbctemplate，因為spring對jdbc進行了封裝，這個是不需要手工關閉的。

finally {
            if(psc instanceof ParameterDisposer) {
                ((ParameterDisposer)psc).cleanupParameters();
            }

            JdbcUtils.closeStatement(ps);
            DataSourceUtils.releaseConnection(con1, this.getDataSource());
        }

public static void releaseConnection(Connection con, DataSource dataSource) {
        try {
            doReleaseConnection(con, dataSource);
        } catch (SQLException var3) {
            logger.debug("Could not close JDBC Connection", var3);
        } catch (Throwable var4) {
            logger.debug("Unexpected exception on closing JDBC Connection", var4);
        }

    }

所以不是jdbctemplate的錯，最後看了原始碼覺得應該是c3p0:

c3p0在從連線池中獲取和返回連線的時候，採用了非同步的處理方式，使用一個執行緒池來非同步的 把返回關閉了（沒有真正關閉）的連線放入連線池中。這樣就意味著，我們在呼叫了從c3p0獲得的連線的close方法時，不是立即放回池中的，而是放入一 個事件佇列中等待c3p0內部的執行緒池順序的處理。所以沒有及時加入到執行緒池中，所以心跳時間監測不到。（也就是我們設定了maxIdleTime的原因）

報以下錯誤：The last packet successfully received from the server was 990,743 milliseconds ago.
連線超時問題，
a.需檢查心跳時間是否小於30秒（這個時間要根據公司MySQL服務端設定的空閒超時斷開時間指定，比如wait_timeout=60s）
b.是否新增 autoReconnect=true（最好加上，但是這個貌似只對mysql5之前的版本起作用）
c.是否在呼叫資料庫connection後沒有close（只有close後才能迴歸連線池，才會去心跳校驗）

備註：1、像mysql重連，連線丟失這種情況，一般發生在一個應用中有多個數據源（多個不同的庫），比如多個執行緒操作，一個執行緒操作了第一個庫之後，第二個執行緒去操作第二個庫同步資料花費了很長的時間，而且第一個庫的連線在mysql中已經失效，這時候連線池中如果不設定maxIdleTime小於mysql的wait_timeout，就會報mysql連線丟失的異常。maxIdleTime還有一個好處就是：空閒連接回收 （長時間不用的連線應該被銷燬），否則會導致連線洩露（另一種記憶體洩露)。

2、在Tomcat中配置c3p0資料庫連線池的時候，如果資料庫重啟，或者網路原因造成伺服器和資料庫斷開連線，Tomcat便再也不能和資料庫連線，除非Tomcat服務重啟。

也就是說無效連線清除。如果客戶端（連線池）保持了若干連線，而資料庫伺服器重啟，那麼客戶端哪些仍被保持的連線實際已經失效。因此必須有檢測機制定期清除無效連線。

也就是這個在前面介紹的配置：

c3p0.testConnectionOnCheckin=true
c3p0.preferredTestQuery=SELECT 1
c3p0.idleConnectionTestPeriod=10

這樣配置之後，連線池每隔10秒自動檢測資料庫連線情況，如果斷開則自動重連。

最後別忘了quartz.properties也要配置上

參考資料：http://www.cnblogs.com/zhishan/archive/2012/11/09/2761980.html

                    http://blog.csdn.net/frankcheng5143/article/details/50589264