情景

項目上線了一個接口，先灰度一臺機器觀察調用情況；

接口不斷的調用，過了一段時間，發現機器上的接口調用開始報 OOM異常 ！

當天就是上線deadline了，刺激。。

發現問題

第一步，使用 jps 命令獲取出問題jvm進程的進程ID

使用 jps -l -m 獲取到當前jvm進程的pid，通過上述命令獲取到了服務的進程號：427726 (此處假設為這個)

jps命令

jps (JVM Process Status Tool)：顯示指定系統內所有的HotSpot虛擬機進程

jps -l -m ： 參數-l列出機器上所有jvm進程，-m顯示出JVM啟動時傳遞給main()的參數

第二步，使用 jstat 觀察jvm狀態，發現問題

因為是OOM異常，所以我們首先重啟機器觀察了JVM的運行情況；

我們使用 jstat -gc pid time 命令觀察GC，發現GC在YGC后，GC掉的內存并不多，每次YGC后都有一部分內存未回收，導致在多次YGC后回收不掉的內存被挪到堆的old區，old滿了之后FGC發現也是回收不掉；

這里基本可以確定是內存泄漏的問題了，下面我們有簡單看了下機器的cpu、內存、磁盤狀態

jstat命令：

jstat (JVM statistics Monitoring)是用于監視虛擬機運行時狀態信息的命令，它可以顯示出虛擬機進程中的類裝載、內存、垃圾收集、JIT編譯等運行數據。

jstat -gc pid time ： -gc 監控jvm的gc信息，pid 監控的jvm進程id，time每隔多少毫秒刷新一次

jstat -gccause pid time ： -gccause 監控gc信息并顯示上次gc原因，pid 監控的jvm進程id，time每隔多少毫秒刷新一次

jstat -class pid time ： -class 監控jvm的類加載信息，pid 監控的jvm進程id，time每隔多少毫秒刷新一次

在這里先簡單說一下，堆的GC：

年齡達到一定值(年齡閾值，可以通過-XX:MaxTenuringThreshold來設置)的對象會被移動到年老代中，沒有達到閾值的對象會被復制到“To”區域。經過這次GC后，Eden區和From區已經被清空。這個時候，“From”和“To”會交換他們的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎樣，都會保證名為To的Survivor區域是空的，minor GC會一直重復這樣的過程。

第三步，觀察機器狀態，確認問題

使用 top -p pid 獲取進程的cpu和內存使用率；查看RES 和 %CPU %MEM三個指標：

在這里先簡單說一下，top命令展示的內容：

VIRT：virtual memory usage 虛擬內存

1、進程“需要的”虛擬內存大小，包括進程使用的庫、代碼、數據等

2、假如進程申請100m的內存，但實際只使用了10m，那么它會增長100m，而不是實際的使用量

RES：resident memory usage 常駐內存

1、進程當前使用的內存大小，但不包括swap out

2、包含其他進程的共享

3、如果申請100m的內存，實際使用10m，它只增長10m，與VIRT相反

4、關于庫占用內存的情況，它只統計加載的庫文件所占內存大小

SHR：shared memory 共享內存

1、除了自身進程的共享內存，也包括其他進程的共享內存

2、雖然進程只使用了幾個共享庫的函數，但它包含了整個共享庫的大小

3、計算某個進程所占的物理內存大小公式：RES – SHR

4、swap out后，它將會降下來

DATA

1、數據占用的內存。如果top沒有顯示，按f鍵可以顯示出來。

2、真正的該程序要求的數據空間，是真正在運行中要使用的。

ps : 如果程序占用內存比較多，說明程序申請內存多，實際使用的空間也多。

如果程序占用虛存比較多，說明程序申請來很多空間，但是沒有使用。

發現機器的自身狀態不存在問題， so毋庸置疑，發現問題了，典型的內存泄漏。。

第四步，使用jmap獲取jvm進程dump文件

我們使用 jmap -dump:format=b,file=dump_file_name pid 命令，將當前機器的jvm的狀態dump下來或缺的一份dump文件，用做下面的分析

jmap命令：

jmap (JVM Memory Map)命令用于生成heap dump文件，還可以查詢finalize執行隊列、Java堆和永久代的詳細信息，如當前使用率、當前使用的是哪種收集器等。

jmap -dump:format=b,file=dump_file_name pid ： file=指定輸出數據文件名， pid jvm進程號

接下來，回滾灰度的機器，開始解決問題=.=

解決問題

第一步，dump文件分析

在這里，我們分析dump文件，使用的 Jprofiler 軟件，就是下面這個東東：

具體的使用方法，在這就不再贅述了，下面將dump文件導入到 Jprofiler 中：

選擇 Heap Walker 中的 Current Object Set ，這里面顯示的是當前的類的占用資源，從占用空間從大到小排序；

從上圖中，沒有觀察出什么問題，我們點擊 Biggest Objects ，查看哪個對象的占用的內存高：

從上圖中，我們發現 org.janusgraph.graphdb.database.StandardJanusGraph 這個對象居然占用了高達 724M 的內存！ 看來內存泄漏八九不離十就是這個對象的問題了！

再點開看看 ，如下圖，可以發現是一個 openTransactions 的類型為 ConcurrentHashMap 的數據結構：

第二步，源碼查找定位代碼

這到底是什么對象呢，去項目中查找一下，打開idea-打開項目-雙擊shift鍵-打開全局類查找-輸入 StandardJanusGraph ，如下圖：

發現是我們項目使用的圖數據庫 janusgraph 的一個類，找到對應的數據結構：

類型定義：

private Set openTransactions;

初始化為一個ConcurrentHashMap：

openTransactions = Collections.newSetFromMap(new ConcurrentHashMap(100, 0.75f, 1));

觀察上述代碼，我們可以看到，里面的存儲的 StandardJanusGraphTx 從字面意義上理解是janusgraph框架中的事務對象，下面往上追一下代碼，看看什么時候會往這個Map中賦值：

// 找到執行openTransactions.add()的方法 public StandardJanusGraphTx newTransaction(final TransactionConfiguration configuration) { if (!isOpen) ExceptionFactory.graphShutdown(); try { StandardJanusGraphTx tx = new StandardJanusGraphTx(this, configuration); tx.setBackendTransaction(openBackendTransaction(tx)); openTransactions.add(tx); // 注意！ 此處對上述的map對象進行了add return tx; } catch (BackendException e) { throw new JanusGraphException("Could not start new transaction", e); } } // 上述發現，是一個newTransaction，創建事務的一個方法，為確保起見，再往上跟找到調用上述方法的類： public JanusGraphTransaction start() { TransactionConfiguration immutable = new ImmutableTxCfg(isReadOnly, hasEnabledBatchLoading, assignIDsImmediately, preloadedData, forceIndexUsage, verifyExternalVertexExistence, verifyInternalVertexExistence, acquireLocks, verifyUniqueness, propertyPrefetching, singleThreaded, threadBound, getTimestampProvider(), userCommitTime, indexCacheWeight, getVertexCacheSize(), getDirtyVertexSize(), logIdentifier, restrictedPartitions, groupName, defaultSchemaMaker, customOptions); return graph.newTransaction(immutable); // 注意！此處調用了上述的newTransaction方法 } // 接著找上層調用，發現了最上層的方法 public JanusGraphTransaction newTransaction() { return buildTransaction().start(); // 此處調用了上述的start方法 }

在我們對圖數據庫中圖數據操作的過程中，采用的是手動創建事務的方式，在每次查詢圖數據庫之前，我們都會調用類似于 dataDao.begin() 代碼，

其中就是調用的 public JanusGraphTransaction newTransaction() 這個方法；

最后，我們簡單的看下源碼可以發現，從上述內存泄漏的map中去除數據的邏輯就是 commit事務的接口，調用鏈如下：

public void closeTransaction(StandardJanusGraphTx tx) { openTransactions.remove(tx); // 從map中刪除StandardJanusGraphTx對象 } private void releaseTransaction() { isOpen = false; graph.closeTransaction(this); // 調用上述closeTransaction方法 vertexCache.close(); } public synchronized void commit() { Preconditions.checkArgument(isOpen(), "The transaction has already been closed"); boolean success = false; if (null != config.getGroupName()) { MetricManager.INSTANCE.getCounter(config.getGroupName(), "tx", "commit").inc(); } try { if (hasModifications()) { graph.commit(addedRelations.getAll(), deletedRelations.values(), this); } else { txHandle.commit(); // 這個commit方法中釋放事務也是調用releaseTransaction } success = true; } catch (Exception e) { try { txHandle.rollback(); } catch (BackendException e1) { throw new JanusGraphException("Could not rollback after a failed commit", e); } throw new JanusGraphException("Could not commit transaction due to exception during persistence", e); } finally { releaseTransaction(); // // 調用releaseTransaction if (null != config.getGroupName() && !success) { MetricManager.INSTANCE.getCounter(config.getGroupName(), "tx", "commit.exceptions").inc(); } } }

終于，我們找到了內存泄漏的根源所在：項目代碼中存在調用了事務 begin 但是沒有 commit的代碼!

第三步，修復問題驗證

解決問題： 找到內存泄漏接口的代碼，并發現了沒有commit()的位置，try-catch-finally中添加上了commit()代碼；

提交-部署-發布-灰度一臺機器后觀察內存泄漏的現象消失，GC回收正常；

內存泄漏問題解決，項目如期上線~

最后

大家，有沒有遇到過內存泄漏的情況，歡迎在評論區說出你的故事=.=

總結

以上是生活随笔為你收集整理的查找这个接口的调用_事务处理不当，线上接口又双叒内存泄漏了！（附图解问题全过程）...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。