1、在前面restTemplate的坑過后，問題又來了，因為數據量並發上去，數據庫壓力很大。cpu相對於之前的壓力一直飆升不下。
在Linux服務器中定位問題
ps -ef | grep 服務名 查看pid
查看整個JVM內存狀態
jmap -heap [pid]
要注意的是在使用CMS GC 情況下，jmap -heap的執行有可能會導致JAVA 進程掛起
查看JVM堆中對象詳細占用情況
jmap -histo [pid]
導出整個JVM 中內存信息
jmap -dump:format=b,file=文件名 [pid]
dump 這一步很關鍵
jhat是sun 1.6及以上版本中自帶的一個用於分析JVM 堆DUMP 文件的工具，基於此工具可分析JVM HEAP 中對象的內存占用情況
jhat -J-Xmx1024M [file]
執行后等待console 中輸入start HTTP server on port 7000 即可使用瀏覽器訪問 IP：7000
eclipse Memory Analyzer
Eclipse 提供的一個用於分析JVM 堆Dump文件的插件。借助這個插件可查看對象的內存占用狀況，引用關系，分析內存泄露等。
采集下來的文件需要為bin類型，在分析的過程中，使用了Windows的電腦打開，直接報錯，仔細查看了后，懷疑是內存溢出，直接放到mac打開，則等了十來分鍾才能打開。具體的操作待我詳細的整理后再提供參考。
當定位到問題后，發現是配置鏈接數過多。默認的database已經吃不下這么多鏈接數。
當時的配置為：
<bean id="dataSource"
class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="${DB.JDBC.DRIVER}" />
<property name="url" value="${DB.JDBC.URL}" />
<property name="username" value="${DB.USERNAME}" />
<property name="password" value="${DB.PASSWORD}" />
</bean>
查看了源碼也是沒有相關鏈接數的配置
因此選擇了阿里的druid修改，代碼量改動控制在最小范圍內。
maven 引用
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.0.29</version>
</dependency>
<bean id="dataSource"
class="com.alibaba.druid.pool.DruidDataSource">
<!-- 配置初始化大小、最小、最大 -->
<property name="initialSize" value="${DB.JDBC.INITIALSIZE}" />
<property name="minIdle" value="${DB.JDBC.MINLDLE}" />
<property name="maxActive" value="${DB.JDBC.MAXACTIVE}" />
<property name="driverClassName" value="${DB.JDBC.DRIVER}" />
<property name="url" value="${DB.JDBC.URL}" />
<property name="username" value="${DB.USERNAME}" />
<property name="password" value="${DB.PASSWORD}" />
</bean>
而且druid也配置了一些監控的事項，具體可以參考wiki
當配置完成后，上線。發現cpu效率提高了50%以上且內存也降低了50%。
有圖有真相
由此總結，將測試環境上的demo代碼放到生產，需要對相應項目的承壓能力以及配置信息進行評估，在合理的條件下進行壓測，以便后續遇到不必要的八阿哥纏繞。
這個坑又順利的抗過去了啦。