一、問題描述
2021-01-06 10:50:00 運維同學反饋生產環境檔案服務節點物理記憶體使用率過高超過運維設定的安全范圍，現象觀察2020-12-17--2021-01-06長時間記憶體無法釋放，
二、問題零時解決方案
- 快速定位問題
根據經驗快速查找影響記憶體使用的指標 老年代、新生代、元空間、非堆記憶體使用、網卡上下行流量、CUP使用率發現這幾類指標正常，程式也沒有使用堆外空間，是誰使用掉這么多記憶體？帶著疑問發現圖6中執行緒數上升趨勢例外，其中執行緒狀態為TIMED_WAITING的執行緒數上升最多，
| 節點監控指標圖匯總 | |
|---|---|
|
|
|
|
|
|
- 問題零時解決
從監控上看來，這個問題有是執行緒無法釋放導致，其持有的記憶體資源也無法釋放，導致節點物理記憶體長期(2020-12-17--2021-01-06)偏高，零時解決辦法重啟節點，重啟節點后觀察一天，節點的記憶體使用沒有在上升，
三、記憶體泄漏原因分析
-
DUMP分析
dump無任何例外，dump分析比較簡單不做多介紹，
-
一個執行緒占用多少記憶體
Linux一條執行緒占用多少記憶體？
#linux默認一個執行緒占用8M記憶體
[logview@vm-xy-vmc-file-p02 ~]$ ulimit -s
8192Java一條執行緒占用多少記憶體？
java執行緒占用記憶體也就是java的堆疊空間大小，可通過-Xss引數設定，除非出現堆疊溢位一般不做設定
[logview@vm-xy-vmc-file-p02 ~]$ java -XX:+PrintFlagsFinal -version | grep ThreadStackSize
intx CompilerThreadStackSize = 0 {pd product}
#應用執行緒大小
intx ThreadStackSize = 1024 {pd product}
#JVM內部執行緒大小比如GC執行緒
intx VMThreadStackSize = 1024 {pd product}
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)Java執行緒 VS Linux執行緒？
相同點：執行緒是作業系統的最小調度單位，都需要獲取CUP時間片的，CUP時間片是先分配給行程，行程在分配給執行緒，
不同點：Java執行緒是屬于JVM行程的執行緒，Linux執行緒分為內核執行緒、用戶執行緒具體與CUP互動的方式都不通，具體不同在哪里目前也不知道，本帖是關于Linux執行緒與Java變成的討論，
-
Java執行緒狀態解讀
NEW 創建、 RUNNABLE 就緒、BLOCKED 阻塞、WAITING 不定時等待、TIMED_WAITING 定時等待、TERMINATED 執行緒終止， 關于更多Thread解讀，
四、問題解決程序
待更新（由于我們執行緒日志被覆寫了，目前無任何線索了，后續遇到類似問題，在繼續分析）
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/246242.html
標籤：其他