今天我們來聊一下 Java 虛擬機生態(tài)核心技術—— 內存泄漏，即 “Memory Leak” 。

在本篇文章中，我們將了解什么是 Java 中的內存泄漏，以及關于 Java 內存泄漏場景的錯誤認知進行簡要解析。

帶你認識 Java 內存泄漏點點滴滴

眾所周知，Java 提供了強大的內存管理機制，使得開發(fā)人員不需要像其他過程性編程語言(如 C 和 C++ )那樣進行手動管理內存。在 Java 生態(tài)中，我們通常使用 new 關鍵字創(chuàng)建對象時，Java 虛擬機(JVM)會自動為該對象分配內存。當該對象不再被應用程序引用時，垃圾收集器會自動識別并回收這些不再使用的對象，從而釋放內存空間供其他對象使用。

盡管 Java 的內存管理機制看似完美，但仍然存在潛在的內存泄漏問題。那么，什么是 Java 中的內存泄漏 ?

通常，在 Java 中，內存泄漏指的是垃圾收集器無法識別不再使用的對象，導致這些對象無限期地駐留在內存中，從而減少了分配給應用程序的可用內存。由于這些未使用的對象仍然被引用，可能會導致內存不足錯誤(OutOfMemoryError)，從而影響應用程序的可靠性和性能。

針對 Java 內存泄露相關原因，大家可參考之前的文章，具體可點擊如下圖片查閱。

Java 內存泄漏的典型場景錯誤認知

關于 Java 虛擬機內存問題的錯誤認知，是指一些常見的誤解或誤導，可能導致對內存管理機制的理解不準確。在開發(fā) Java 應用程序時，理解和正確處理內存是至關重要的。本文將基于筆者 10 多年的一線經(jīng)驗，簡單介紹一些常見的錯誤認知，幫助大家建立正確的 Java 虛擬機內存知識體系。

認知 1： “重啟” 將會解決內存泄露問題

ITOps 團隊經(jīng)常采取快速修復措施，比如重新啟動應用程序或服務器。這是 99% 的技術人員經(jīng)常干的事情。然而，僅僅重新啟動應用程序本身并不能釋放所有不正確分配的內存，通常只能釋放正確分配的內存。不正確分配的內存需要通過常規(guī)垃圾收集來清理，因此重新啟動應用程序只能暫時解決問題，而問題很可能會再次出現(xiàn)。

重新啟動應用程序服務或服務器可以重置內存狀態(tài)，但從長遠來看，任何導致內存泄漏的問題都有可能再次發(fā)生，而且可能更加頻繁。定期重新啟動服務器表明存在應用程序問題，我們的應用程序可能會無謂地消耗資源，并暴露于性能問題和速度減慢的風險中。忽視應用程序問題的跡象是不明智的。

因此，除了簡單地重新啟動應用程序或服務器外，ITOps 團隊應該致力于解決潛在的應用程序問題。我們可以通過分析和優(yōu)化代碼、進行內存泄漏檢測和修復、進行性能優(yōu)化等方式來解決這些問題。通過采取這些措施，可以提高應用程序的穩(wěn)定性、性能和效率，減少不必要的資源消耗，并避免頻繁的重新啟動操作。

認知 2： “擴容” 將消滅一切內存問題

除了上述認知 1 的“重啟”操作，“擴容”行為在解決內存泄露時，也是經(jīng)常采取的一種措施。

其實，從本質上而言，大多數(shù)的內存泄漏就像一個無底洞，無止境地吞噬著資源。我們投入的資源越多，它就越貪婪地索取更多。最終，將耗盡可用內存，而無法預測應用程序何時會達到內存上限，一旦達到上限，我們的生產(chǎn)服務將受到嚴重影響。

舉個簡單的場景：假設我們的核心平臺服務存在內存泄漏。隨著越來越多的用戶同時，系統(tǒng)最終會因內存耗盡而崩潰，出現(xiàn) OutOfMemoryError 錯誤。

如果我們依賴云基礎設施，如 Google GCP(Google Cloud Platform)、Microsoft Azure 或國內阿里、華為以及騰訊云等，并根據(jù)資源使用和按需付費的定價模式進行支付，那么意味著我們要為解決內存泄漏而浪費的不必要資源將對我們所構建的業(yè)務利潤和預算產(chǎn)生影響。我們可以將這些開支用于更有意義的事務上。

因此，及時發(fā)現(xiàn)和修復內存泄漏問題對于確保應用程序的穩(wěn)定性和性能至關重要。通過進行定期的性能分析、內存監(jiān)測和代碼審查，我們可以捕捉并解決潛在的內存泄漏問題。這樣不僅可以避免系統(tǒng)崩潰和服務中斷，還可以節(jié)省資源成本，讓我們的業(yè)務能夠專注于更有價值的方面。

認知 3： Java 具有自動內存管理，無需對其進行干涉

有時候技術人員錯誤地認為 Java 完全不需要關注內存管理，因為它具有自動垃圾回收機制。然而，這種觀點是誤導性的。雖然 Java 提供了自動垃圾回收，但仍然需要開發(fā)人員關注內存的分配和釋放，以避免內存泄漏等問題。

現(xiàn)實的情況是：我們的“屎山”代碼往往或多或少存在如下問題，從而導致內存泄漏現(xiàn)象可能發(fā)生：

• 未取消引用創(chuàng)建的對象：在代碼中創(chuàng)建對象后，如果沒有適時地取消對這些對象的引用，垃圾收集器將無法回收它們，從而導致內存泄漏。
• 保留 HashMap 或 HashSet 中的靜態(tài)對象： 在靜態(tài)集合對象(如 HashMap 或 HashSet)中保留對象的引用，即使這些對象不再需要，也會導致內存泄漏。確保在不再需要時及時從靜態(tài)集合中移除對象引用，以避免內存泄漏。
• 未關閉 JDBC 連接、ResultSet 和語句對象、文件句柄和套接字等資源： 在使用需要手動管理的資源時，如 JDBC 連接、ResultSet 和語句對象、文件句柄和套接字等，如果沒有正確地關閉或釋放這些資源，會導致資源泄漏和內存泄漏。
• 在 ThreadLocal 中保留對對象的引用而不清理： ThreadLocal 是一種線程本地變量，如果在 ThreadLocal 中保留對對象的引用，而在不再需要時沒有清理它們，將導致對象一直存在于內存中，引發(fā)內存泄漏。

為避免這些問題，在實際的項目開發(fā)活動中，我們需要遵循良好的編程實踐，及時取消對象引用，正確關閉資源以及謹慎使用 ThreadLocal，可以最大程度地避免內存泄漏問題，提高應用程序的性能和可靠性。

認知 4： 內存泄露主要出現(xiàn)在高并發(fā)場景

其實，基于歷史經(jīng)驗教訓，內存泄露可以在任何場景下出現(xiàn)，不僅限于高并發(fā)場景。內存泄露的根本原因是程序中存在某些內存無法被自動回收，這與并發(fā)量沒直接關系。

但由于高并發(fā)場景下，同一問題發(fā)生的頻率更高，內存占用也更容易突破閾值，因此內存泄露的問題更容易被發(fā)現(xiàn)和注意。這種現(xiàn)象讓人容易聯(lián)想為“內存泄露只在高并發(fā)場景出現(xiàn)”，但實際上是兩個沒有必然聯(lián)系的問題。

內存泄漏不僅可能發(fā)生在高并發(fā)或高流量的應用場景，也同樣可能隱藏在流量較小或使用水平較低的應用程序中。這類內存泄漏問題可能起初非常難以被發(fā)現(xiàn)，但會隨著時間推移而逐步積累，最終導致應用程序運行崩潰或宕機。

特別是在當前微服務架構盛行的背景下，許多企業(yè)會部署運行大量微小的服務實例。這樣一來，每個單個微服務實例的內存泄漏問題所造成的影響似乎很小，容易被忽略，但這些服務實例的數(shù)量又非常多，分布廣泛，長時間累積下來，聚合起來的內存泄漏問題可能會是非常嚴重的。

如果不能有效監(jiān)控和發(fā)現(xiàn)這些個別服務中的內存泄漏問題，并及時排查修復，它們就可能“藏”在系統(tǒng)中，成為一個不易察覺的巨大隱患。當達到某個臨界點后，可能會突然爆發(fā)，導致整個系統(tǒng)或關鍵業(yè)務不可用。

所以，我們不能忽視任何個別服務或應用中的潛在內存泄漏問題。必須建立起全面的監(jiān)控體系，確保能及時發(fā)現(xiàn)任何級別的應用中的內存泄漏情況，并快速定位修復，避免問題積累擴大到不可控的地步。

認知 5： 哥的代碼杠杠的，應該不會有問題

通常而言，代碼質量跟內存泄漏沒有絕對的正比例關系。代碼質量是指代碼的可讀性、可維護性、健壯性等方面的評價。雖然高質量的代碼可以提高程序的可靠性和性能，但并不能保證絕對沒有內存泄漏問題。即使代碼在其他方面達到了高質量的標準，仍然有可能存在內存泄漏的風險。

由于軟件開發(fā)通常在動態(tài)環(huán)境中進行，涉及多線程、并發(fā)訪問、異步操作等復雜情況。這些因素增加了內存泄漏問題的潛在風險。即使代碼質量較高，也需要在實際運行環(huán)境中進行充分的測試和監(jiān)控，以確保沒有內存泄漏問題。

除此之外，作為技術人員，我們必須明白，我們編寫的代碼再完美和嚴謹，也無法完全避免依賴的第三方庫中可能存在的內存泄漏問題。

我們在項目中不可避免需要依賴各種第三方庫和框架，這已經(jīng)成為現(xiàn)代軟件開發(fā)的基本情況。這些依賴庫中，即使是非常優(yōu)秀和流行的項目，也很難完全杜絕內存泄漏的風險。

更糟糕的是，我們通常需要依賴多個第三方庫，它們之間的交互也可能產(chǎn)生無法預知的內存問題。即使每個第三方庫的質量都很高，組合使用時還是可能出現(xiàn)意想不到的問題。

所以我們必須對系統(tǒng)中的所有第三方依賴保持高度的警惕。需要采取各種手段，比如靜態(tài)代碼分析、運行時檢測等方式，盡可能提前發(fā)現(xiàn)第三方庫中的內存泄漏問題。一旦發(fā)現(xiàn)，需要及時跟進第三方維護者解決。

同時，我們在開發(fā)自己的代碼時，也要考慮依賴的不確定性。采取更嚴謹?shù)木幋a方式，進行徹底的單元測試，降低問題擴散的風險。這樣，即使依賴存在問題，也能將影響控制在最小范圍。

認知 6： 老版本框架才有出現(xiàn)內存泄漏問題

內存泄漏是一個影響所有 Java 版本的潛在問題，包括最新版本在內。我們不能因使用了新版本而降低警惕。

事實上，Java 的一些新功能和改進，在解決舊版問題的同時，有時也會無意中引入新的內存泄漏源。這主要是由于新功能的邊界案例沒有完全覆蓋到。比如在 Java 11.0.16 版本中,就發(fā)現(xiàn)了與 C2 JIT 編譯器相關的內存泄漏問題，嚴重影響了一些流行應用如 Jenkins。

這個例子表明，即使我們的源代碼嚴格規(guī)范，也不能完全避免因編譯器等其他環(huán)節(jié)引入的內存泄漏。這種編譯器導致的內存泄漏又較難排查，需要借助專業(yè)工具才能發(fā)現(xiàn)。

綜上所述，內存泄漏是一個跨版本的潛在隱患，同時也需要警惕來自編譯器等外部因素導致的內存泄漏。我們必須對任何 Java 版本都保持高度重視，多途徑全面監(jiān)測內存情況，一旦發(fā)現(xiàn)異常，立即進行排查分析，主動查找潛在內存泄漏問題，而不能被動等待問題顯現(xiàn)。

認知 7： 內存型應用才有出現(xiàn)內存泄漏問題

我們需要清楚的是，應用程序占用大量內存資源與存在內存泄漏是兩個不同的形態(tài)。

有一些應用程序由于其功能特點，天生需要占用非常大量的內存才能保證服務質量，比如緩存系統(tǒng)、大數(shù)據(jù)處理平臺等。當這類應用程序啟動時，我們通常會看到內存占用快速飆升。但是這種情況下，只要內存占用處于某個穩(wěn)定水平，并不會無限增長，那么就不屬于內存泄漏。

嚴格意義上來講，內存泄漏主要指的是應用程序中的內存占用隨時間推移而永無止境地增長，這通常是由于存在釋放內存的代碼缺陷導致。對于本身就需要大量內存的應用，我們需要區(qū)分正常的內存占用增長和內存泄漏導致的不正常增長。

在實際的業(yè)務場景中，當觀測到內存占用激增時，我們不能草率地就判斷存在內存泄漏。需要進一步觀察占用量隨時間是否穩(wěn)定、是否會釋放、是否會增長到系統(tǒng)資源耗盡等。結合應用類型和場景，才能對根源進行準確判斷。區(qū)分占用量增長的性質，再采取針對性的優(yōu)化措施，才是應對之道。

認知 8： 主流 GC 策略可以避免內存泄漏問題

在軟件項目開發(fā)活動中，有時候人們傾向于跟隨潮流，這意味著他們會看到其他人家或項目中運用先進技術以最大化性能，并希望將這些成功經(jīng)驗應用到自己的項目中。然而，由于項目的特性、架構的差異以及框架的版本特性，這種模仿行為往往導致了失敗和困惑。

在軟件開發(fā)領域，技術的快速演進和變化意味著新的工具、框架和方法不斷涌現(xiàn)。當開發(fā)人員看到其他項目取得成功時，他們可能會嘗試復制那些成功的因素，期望獲得類似的結果。這種跟風心態(tài)很常見，因為人們希望能夠節(jié)省時間和精力，避免自己犯錯或重復發(fā)明輪子。

然而，項目的特性和需求往往是獨特的，每個項目都有其獨特的目標、范圍和約束條件。對于不同的項目，采用同一種技術或方法并不能保證獲得相同的成功結果。項目的特性可能涉及不同的業(yè)務領域、不同的用戶需求、不同的性能要求等等。此外，項目的架構和框架版本也可能不同，這會導致在復制別人的成功經(jīng)驗時出現(xiàn)問題。

當人們盲目跟風而沒有深入理解技術和其適用性時，很容易在項目中遇到挫折和問題?？赡軙l(fā)現(xiàn)所選的技術與項目需求不匹配，或者在實施過程中遇到了無法解決的兼容性或性能問題。這種情況下，就會發(fā)生翻車，即項目遇到嚴重的失敗或困難。

最為典型的場景便是 Java 虛擬機參數(shù)的配置，基于較老的框架、底層 OS 以及落后的技術堆棧，使得在實際的業(yè)務場景中，期望能夠采用主流的 GC 策略以解決內存泄漏問題。然而，不幸的事，主流的 GC 策略可以幫助自動管理內存，但并不能完全避免內存泄漏問題。開發(fā)人員仍然需要在編碼中注意避免保持不必要的強引用、處理循環(huán)引用等情況，以確保程序的內存使用是有效和可控的。雖然 GC 可以幫助減少手動內存管理的負擔，但對于確保內存泄漏問題的解決，仍需要開發(fā)人員的主動參與和正確的編碼實踐。