一. 問題描述

        本人所在的專案組專案已經執行快一年了，功能效能都比較穩定。但是最近釋出了一個版本，只是業務上增加了一些資料量，最終效果卻是在持續執行的過程中，出現OOM異常。之前也發過一些版本，做過一些類似的調整，都沒有出現效能問題，而這個版本卻出現了，著實手忙腳亂了一陣子。

二. 專案背景

         專案是一個為前臺提供服務的後臺應用。出問題的功能主要做的事情是：通過各個表的基礎資料，進行計算，得到一個結果資料，併入庫。而且明確是在執行這個功能的時候出的問題。我們在上線之前，也做過效能測試，持續跑了很久也沒有出現這樣的問題。

        資料入庫的方式，一般都是使用單條insert語句sql標籤，再通過batchUpdate方法，在同一個事務中執行批量sql呼叫操作。我們為了提高結果資料的入庫效率，使用insert into tablename (colum1,…,columN)values (…),(…),…,(…) 這種方式，將資料合併到一條sql中入庫。但是mybatis的:param（冒號加引數名是SpringJDBC接受的一種傳參方式）不支援傳遞 (…),(…),…,(…) 這樣的引數（因為SpringJDBC會將:param解析成?佔位符，然後insert into tablename (colum1,…,columN)values ? 這個語句不符合PreparedStatement的語法，報異常）。於是我們採用${param}方式，在FreeMarker層解析，直接拼接出包括具體值的完整的insert語句。

        作業系統Linux，JDK1.6版本，應用伺服器用的是IBM的websphere叢集。

三. 問題定位

        在一年前釋出初始版本前，我們也曾出現過OOM異常。當時的解決方案，一方面調大JVM啟動記憶體和最大記憶體，另一方面，在運算過程中用來儲存計算結果的List、Map之類的“大集合”，手動clear操作，減輕GC壓力（為什麼能減輕？和GC策略有關，不細說了）。

        時隔一年，又出現這樣的問題，我們第一反應還是檢查有沒有正確處理新增的“大集合”。結果是沒問題的。

        看來想通過程式碼走讀來解決問題是行不通了，只好試著做一下記憶體分析、執行緒分析、GC分析（老實講，沒怎麼用過，現學現賣）。

        先看GC分析。用的是IBM提供的ga16.jar工具（IBM Pattern Modeling and Analysis Tool forJava Garbage Collector）。拉了一段時間的GC日誌分析了下，結果如下圖：

        從功能開始執行，雖然有GC，但是消耗的速度大於GC的程度。這樣看來，即使分配的記憶體再調大一些，也許能解決當下的問題，但是將來如果結果資料繼續增大，可能還會出現同樣的問題，治標不治本。

        再看執行緒分析的結果。使用工具jca452.jar（IBM Thread and Monitor Dump Analyzer for Java）分析javaCore檔案：

圖2

圖3

       看起來資料庫操作那塊有問題的。我們排查了資料庫當時的執行情況，是非常良好的：系統負載正常，連線數正常。因此，初步確定是服務端操作資料庫那塊有問題。

最後我們再分析當時的記憶體dump檔案。工具是ha426.jar（IBM HeapAnalyzer）。通過此工具的“洩露嫌疑”排序功能發現，消耗記憶體較多的是org.springframework.jdbc.core.namedparam.NamedParameterJdbcTemplate這個類裡面的某個LinkedHashMap物件佔用記憶體較大。我們看看NamedParameterJdbcTemplate原始碼，把相關程式碼段摳出來：

<span style="font-size:18px;">public class NamedParameterJdbcTemplate implements NamedParameterJdbcOperations {

...

	/** Cache of original SQL String to ParsedSql representation */
	private final Map<String, ParsedSql> parsedSqlCache =
			new LinkedHashMap<String, ParsedSql>(DEFAULT_CACHE_LIMIT, 0.75f, true) {
				@Override
				protected boolean removeEldestEntry(Map.Entry<String, ParsedSql> eldest) {
					return size() > getCacheLimit();
				}
			};

...

	/**
	 * Obtain a parsed representation of the given SQL statement.
	 * <p>The default implementation uses an LRU cache with an upper limit
	 * of 256 entries.
	 * @param sql the original SQL
	 * @return a representation of the parsed SQL statement
	 */
	protected ParsedSql getParsedSql(String sql) {
		if (getCacheLimit() <= 0) {
			return NamedParameterUtils.parseSqlStatement(sql);
		}
		synchronized (this.parsedSqlCache) {
			ParsedSql parsedSql = this.parsedSqlCache.get(sql);
			if (parsedSql == null) {
				parsedSql = NamedParameterUtils.parseSqlStatement(sql);
				this.parsedSqlCache.put(sql, parsedSql);
			}
			return parsedSql;
		}
	}

}</span>

        此類實現一個介面，成員屬性只有parsedSqlCache是LinkedHashMap型別的。通過屬性的註釋，以及和它直接相關的方法簽名看出，parsedSqlCache是用來快取預編譯的sql的。

        那麼為什麼這個parsedSqlCache會很大呢？這和我們處理SQL標籤的順序有關。我們會在呼叫getParsedSql方法之前，對SQL標籤進行FreeMarker解析，將${param}替換掉。這樣，getParsedSql方法的sql入參就變成insert into tablename (colum1,…,columN) values (…),(…),…,(…)這樣的一個超長SQL了。要知道，我們結果表字段很多，而且每個欄位也都很大，這樣組成的超長記錄數SQL，一條SQL就能達到幾十兆。因為每個insert拼接的條目記錄不一樣，每一條SQL都是一條新的，在parsedSqlCache沒有值，因此每來一條SQL都會put到parsedSqlCache中，parsedSqlCache的size預設為256。這樣算來，記憶體消耗是很大的，而且這些SQL的控制代碼被parsedSqlCache持有，是強引用，因此GC也回收不了。

        癥結找到了，就好辦了。要麼調整FreeMarker的解析順序，要麼調整SQL標籤的使用方式。考慮到FreeMarker解析那塊是共方法，修改的話影響很大，最終我們選擇使用:param方式傳參，構建單條insert固定句式，然後在一個事務中批量執行不同記錄的insert操作。問題得以解決。

        除了以上兩種方法以外，還可以通過調整NamedParameterJdbcTemplate類屬性的方式，不使用SQL快取措施。仔細看下getParsedSql方法的第一行：if (getCacheLimit() <= 0) 。這個判斷，如果parsedSqlCache的size設定為空，則直接解析入參SQL，不做快取處理。但是這樣的話，常規SQL處理也沒有預處理快取了，會降低SQL執行效率。看怎麼取捨吧！

        以上是這次記憶體洩露問題的一個小結，希望對大家有所啟發。