## 狀況描述：
最近專案新打的版本，過不了多長時間，專案就會掛掉。狀況就是處於一種假死的狀態。索引查詢都很慢，幾乎進行不了任何操作，慢慢卡死。
然後我們再發版時，只能基於之前打好的war包，替換或者增加class檔案。

## 情況對比及分析：
由於之前程式碼做過一次大整頓，提交的程式碼比較多，所以透過回滾版本的方式解決，比較困難。一是因為整頓的成果不能白白抹殺；二是那麼多檔案，靠人工挨個對比查詢，比較困難。

### 解決方案一：

之前， 一直對目前專案的打包方式心存質疑，所以這次發生問題時，我首先懷疑的物件是Jenkins和生產的Tomcat伺服器。我透過堡壘機連線到生產時，發現透過Jenkins啟動應用程式，會啟動兩個兩個tomcat程式。

![](http://college.creditease.cn/resources/upload/image/20200616/1592298669444077954.png)

然後，這似乎更加堅定了我的看法，馬上就找到了運維，但是經確認後，是沒有問題的。一個是用root使用者啟動的，一個是用tomcat使用者啟動的。一個守護程式，一個應用程式。

### 解決方案二：
排除了伺服器的問題，開始正面考慮程式的問題。
重新發專案有問題的版本，Dump下來的日誌，然後迅速回滾觀察。單臺機器的dump日誌有5個G：

透過Memory Analyzer分析，在Leak Supects Report 檢視中，有如下分析結果：

![](http://college.creditease.cn/resources/upload/image/20200616/1592298682003027073.png)

上圖所示，共有三類問題a、b、c；還有一些其他的，型別為d。

先來看第一個問題（後來發現，前幾個問題都是同一個問題）

![](http://college.creditease.cn/resources/upload/image/20200616/1592298691147059654.png)

先點開Details看一下：

![](http://college.creditease.cn/resources/upload/image/20200616/1592298705527077759.png)

上圖顯示了一個很明顯的有問題的執行緒：地址是0x7c8ff3df0 ，名稱為pool-16-thread-1。
透過《Accumulated Objects in Dominator Tree》檢視可以看出，在該執行緒中，存在一個大的List物件，List物件記憶體放了大量的mysql的jdbc物件。

我們想看看JDBC物件裡面堆放了哪些資料。接下來我們開啟《open dominator tree for entire heap》這個檢視：

![](http://college.creditease.cn/resources/upload/image/20200616/1592298722438012273.png)

找到名為0x7c8ff3df0 pool-16-thread-1的執行緒。如圖也能發現，這個執行緒佔用了大量的空間未釋放。一層層開啟裡面的存放的物件：

![](http://college.creditease.cn/resources/upload/image/20200616/1592298737025090019.png)

這裡的資料，是我們的一張使用者表的資料。所以這就可以得出結論：一個執行緒內，一個list記憶體放了大量從資料庫中獲取的使用者物件！
想到這裡，我們又去看了b、c的問題描述，也是同樣的問題。估計是在不同時間點，透過gc已經回收了部分。

然後，我剛才看了a問題的details資訊，接下來我們看下a的stacktrace 堆疊資訊。

![](http://college.creditease.cn/resources/upload/image/20200616/1592298746343031352.png)

如上圖，問題就很明顯了，在Service的112行中，呼叫的findByCustomerID方法中，有掃描全表的操作。經過分析，找到對應的位置，對應的程式碼為：

```
customerID = StringUtils.isNotBlank(customerID)?customer.getCustomer().getCustomerID():null;

Customer oldCutsomer = customerService.findByCustomerID(customerID);

```

顯而易見，流程走到這裡時，customerID永遠為空，那麼customerService.findByCustomerID(customerID)方法，會執行掃描全表操作。由於該表資料量巨大，開發所認為的使用者每次執行的索引查詢，實際上都成了慢查詢，而且需要返回全表資料。大量執行緒過來，佔用大量資料庫連線，導致資料庫連線數不夠；而每個執行緒處理時，需要大量時間，  導致專案處於一種假死的狀態。

## 總結分析：

1、在工作中一定要規範程式碼管理，才能提升開發效率，降低企業遭受損失的風險；

2、透過這次實踐發現，目前開發許可權小，導致跨部門協同效率不是很高，接下來的開發中，立項之初就建立專案開發流程，從而提升開發效率；

3、解決問題的方法遇到瓶頸，嘗試第二種方法，多角度多層次對問題進行突破。

> 作者：宜信技術學院 劉正權

記一次透過Memory Analyzer分析記憶體洩漏的解決過程

相關文章