阿裡面試100%問到,JVM性能調優篇

来源:https://www.cnblogs.com/yuxiang1/archive/2019/04/13/10702967.html
-Advertisement-
Play Games

JVM 調優概述 性能定義 吞吐量 - 指不考慮 GC 引起的停頓時間或記憶體消耗,垃圾收集器能支撐應用達到的最高性能指標。 延遲 - 其度量標準是縮短由於垃圾啊收集引起的停頓時間或者完全消除因垃圾收集所引起的停頓,避免應用運行時發生抖動。 記憶體占用 - 垃圾收集器流暢運行所需要的記憶體數量。 調優原則 ...


JVM 調優概述

性能定義

  • 吞吐量 - 指不考慮 GC 引起的停頓時間或記憶體消耗,垃圾收集器能支撐應用達到的最高性能指標。
  • 延遲 - 其度量標準是縮短由於垃圾啊收集引起的停頓時間或者完全消除因垃圾收集所引起的停頓,避免應用運行時發生抖動。
  • 記憶體占用 - 垃圾收集器流暢運行所需要的記憶體數量。

調優原則

GC 優化的兩個目標:

  1. 將進入老年代的對象數量降到最低
  2. 減少 Full GC 的執行時間

GC 優化的基本原則是:將不同的 GC 參數應用到兩個及以上的伺服器上然後比較它們的性能,然後將那些被證明可以提高性能或減少 GC 執行時間的參數應用於最終的工作伺服器上。

將進入老年代的對象數量降到最低

除了可以在 JDK7 及更高版本中使用的 G1 收集器以外,其他分代 GC 都是由 Oracle JVM 提供的。關於分代 GC,就是對象在 Eden 區被創建,隨後被轉移到 Survivor 區,在此之後剩餘的對象會被轉入老年代。也有一些對象由於占用記憶體過大,在 Eden 區被創建後會直接被傳入老年代。老年代 GC 相對來說會比新生代 GC 更耗時,因此,減少進入老年代的對象數量可以顯著降低 Full GC 的頻率。你可能會以為減少進入老年代的對象數量意味著把它們留在新生代,事實正好相反,新生代記憶體的大小是可以調節的。

降低 Full GC 的時間

Full GC 的執行時間比 Minor GC 要長很多,因此,如果在 Full GC 上花費過多的時間(超過 1s),將可能出現超時錯誤。

  • 如果通過減小老年代記憶體來減少 Full GC 時間,可能會引起 OutOfMemoryError 或者導致 Full GC 的頻率升高。
  • 另外,如果通過增加老年代記憶體來降低 Full GC 的頻率,Full GC 的時間可能因此增加。

因此,你需要把老年代的大小設置成一個“合適”的值。

GC 優化需要考慮的 JVM 參數

類型參數描述堆記憶體大小-Xms啟動 JVM 時堆記憶體的大小-Xmx堆記憶體最大限制新生代空間大小-XX:NewRatio新生代和老年代的記憶體比-XX:NewSize新生代記憶體大小-XX:SurvivorRatioEden 區和 Survivor 區的記憶體比

GC 優化時最常用的參數是-Xms,-Xmx-XX:NewRatio-Xms-Xmx參數通常是必須的,所以NewRatio的值將對 GC 性能產生重要的影響。

有些人可能會問如何設置永久代記憶體大小,你可以用-XX:PermSize-XX:MaxPermSize參數來進行設置,但是要記住,只有當出現OutOfMemoryError錯誤時你才需要去設置永久代記憶體。

GC 優化的過程

GC 優化的過程和大多數常見的提升性能的過程相似,下麵是筆者使用的流程:

1.監控 GC 狀態

你需要監控 GC 從而檢查系統中運行的 GC 的各種狀態。

2.分析監控結果後決定是否需要優化 GC

在檢查 GC 狀態後,你需要分析監控結構並決定是否需要進行 GC 優化。如果分析結果顯示運行 GC 的時間只有 0.1-0.3 秒,那麼就不需要把時間浪費在 GC 優化上,但如果運行 GC 的時間達到 1-3 秒,甚至大於 10 秒,那麼 GC 優化將是很有必要的。

但是,如果你已經分配了大約 10GB 記憶體給 Java,並且這些記憶體無法省下,那麼就無法進行 GC 優化了。在進行 GC 優化之前,你需要考慮為什麼你需要分配這麼大的記憶體空間,如果你分配了 1GB 或 2GB 大小的記憶體並且出現了OutOfMemoryError,那你就應該執行**堆快照(heap dump)**來消除導致異常的原因。

註意:
**堆快照(heap dump)**是一個用來檢查 Java 記憶體中的對象和數據的記憶體文件。該文件可以通過執行 JDK 中的jmap命令來創建。在創建文件的過程中,所有 Java 程式都將暫停,因此,不要在系統執行過程中創建該文件。
你可以在互聯網上搜索 heap dump 的詳細說明。

3.設置 GC 類型/記憶體大小

如果你決定要進行 GC 優化,那麼你需要選擇一個 GC 類型並且為它設置記憶體大小。此時如果你有多個伺服器,請如上文提到的那樣,在每台機器上設置不同的 GC 參數並分析它們的區別。

4.分析結果

在設置完 GC 參數後就可以開始收集數據,請在收集至少 24 小時後再進行結果分析。如果你足夠幸運,你可能會找到系統的最佳 GC 參數。如若不然,你還需要分析輸出日誌並檢查分配的記憶體,然後需要通過不斷調整 GC 類型/記憶體大小來找到系統的最佳參數。

5.如果結果令人滿意,將參數應用到所有伺服器上並結束 GC 優化

如果 GC 優化的結果令人滿意,就可以將參數應用到所有伺服器上,並停止 GC 優化。

在下麵的章節中,你將會看到上述每一步所做的具體工作。

命令

jmap

jmap 即 JVM Memory Map。

jmap 用於生成 heap dump 文件。

如果不使用這個命令,還可以使用 -XX:+HeapDumpOnOutOfMemoryError 參數來讓虛擬機出現 OOM 的時候,自動生成 dump 文件。

jmap 不僅能生成 dump 文件,還可以查詢 finalize 執行隊列、Java 堆和永久代的詳細信息,如當前使用率、當前使用的是哪種收集器等。

命令格式:

jmap [option] LVMID

option 參數:

  • dump - 生成堆轉儲快照
  • finalizerinfo - 顯示在 F-Queue 隊列等待 Finalizer 線程執行 finalizer 方法的對象
  • heap - 顯示 Java 堆詳細信息
  • histo - 顯示堆中對象的統計信息
  • permstat - to print permanent generation statistics
  • F - 當-dump 沒有響應時,強制生成 dump 快照

示例:jmap -dump PID 生成堆快照

dump 堆到文件,format 指定輸出格式,live 指明是活著的對象,file 指定文件名

$ jmap -dump:live,format=b,file=dump.hprof 28920
Dumping heap to /home/xxx/dump.hprof ...
Heap dump file created

dump.hprof 這個尾碼是為了後續可以直接用 MAT(Memory Anlysis Tool)打開。

示例:jmap -heap 查看指定進程的堆信息

註意:使用 CMS GC 情況下,jmap -heap 的執行有可能會導致 java 進程掛起。

jmap -heap PID
[root@chances bin]# ./jmap -heap 12379
Attaching to process ID 12379, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 17.0-b16

using thread-local object allocation.
Parallel GC with 6 thread(s)

Heap Configuration:
   MinHeapFreeRatio = 40
   MaxHeapFreeRatio = 70
   MaxHeapSize      = 83886080 (80.0MB)
   NewSize          = 1310720 (1.25MB)
   MaxNewSize       = 17592186044415 MB
   OldSize          = 5439488 (5.1875MB)
   NewRatio         = 2
   SurvivorRatio    = 8
   PermSize         = 20971520 (20.0MB)
   MaxPermSize      = 88080384 (84.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 9306112 (8.875MB)
   used     = 5375360 (5.1263427734375MB)
   free     = 3930752 (3.7486572265625MB)
   57.761608714788736% used
From Space:
   capacity = 9306112 (8.875MB)
   used     = 3425240 (3.2665634155273438MB)
   free     = 5880872 (5.608436584472656MB)
   36.80634834397007% used
To Space:
   capacity = 9306112 (8.875MB)
   used     = 0 (0.0MB)
   free     = 9306112 (8.875MB)
   0.0% used
PS Old Generation
   capacity = 55967744 (53.375MB)
   used     = 48354640 (46.11457824707031MB)
   free     = 7613104 (7.2604217529296875MB)
   86.39733629427693% used
PS Perm Generation
   capacity = 62062592 (59.1875MB)
   used     = 60243112 (57.452308654785156MB)
   free     = 1819480 (1.7351913452148438MB)
   97.06831451706046% used

 

jstack

jstack 用於生成 java 虛擬機當前時刻的線程快照。

線程快照是當前 java 虛擬機內每一條線程正在執行的方法堆棧的集合,生成線程快照的主要目的是定位線程出現長時間停頓的原因,如線程間死鎖、死迴圈、請求外部資源導致的長時間等待等。

線程出現停頓的時候通過 jstack 來查看各個線程的調用堆棧,就可以知道沒有響應的線程到底在後臺做什麼事情,或者等待什麼資源。 如果 java 程式崩潰生成 core 文件,jstack 工具可以用來獲得 core 文件的 java stack 和 native stack 的信息,從而可以輕鬆地知道 java 程式是如何崩潰和在程式何處發生問題。另外,jstack 工具還可以附屬到正在運行的 java 程式中,看到當時運行的 java 程式的 java stack 和 native stack 的信息, 如果現在運行的 java 程式呈現 hung 的狀態,jstack 是非常有用的。

命令格式:

jstack [option] LVMID

option 參數:

  • -F - 當正常輸出請求不被響應時,強制輸出線程堆棧
  • -l - 除堆棧外,顯示關於鎖的附加信息
  • -m - 如果調用到本地方法的話,可以顯示 C/C++的堆棧

jps

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

命令格式:

jps [options] [hostid]

option 參數:

  • -l - 輸出主類全名或 jar 路徑
  • -q - 只輸出 LVMID
  • -m - 輸出 JVM 啟動時傳遞給 main()的參數
  • -v - 輸出 JVM 啟動時顯示指定的 JVM 參數

其中[option]、[hostid]參數也可以不寫。

$ jps -l -m
28920 org.apache.catalina.startup.Bootstrap start
11589 org.apache.catalina.startup.Bootstrap start
25816 sun.tools.jps.Jps -l -m

 

jstat

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

命令格式:

jstat [option] LVMID [interval] [count]

參數:

  • [option] - 操作參數
  • LVMID - 本地虛擬機進程 ID
  • [interval] - 連續輸出的時間間隔
  • [count] - 連續輸出的次數

jhat

jhat(JVM Heap Analysis Tool),是與 jmap 搭配使用,用來分析 jmap 生成的 dump,jhat 內置了一個微型的 HTTP/HTML 伺服器,生成 dump 的分析結果後,可以在瀏覽器中查看。

註意:一般不會直接在伺服器上進行分析,因為 jhat 是一個耗時並且耗費硬體資源的過程,一般把伺服器生成的 dump 文件複製到本地或其他機器上進行分析。

命令格式:

jhat [dumpfile]

jinfo

jinfo(JVM Configuration info),用於實時查看和調整虛擬機運行參數。

之前的 jps -v 口令只能查看到顯示指定的參數,如果想要查看未被顯示指定的參數的值就要使用 jinfo 口令

命令格式:

jinfo [option] [args] LVMID

option 參數:

  • -flag : 輸出指定 args 參數的值
  • -flags : 不需要 args 參數,輸出所有 JVM 參數的值
  • -sysprops : 輸出系統屬性,等同於 System.getProperties()

 

HotSpot VM 參數

詳細參數說明請參考官方文檔:Java HotSpot VM Options,這裡僅列舉常用參數。

JVM 記憶體配置

配置描述-Xms堆空間初始值。-Xmx堆空間最大值。-XX:NewSize新生代空間初始值。-XX:MaxNewSize新生代空間最大值。-Xmn新生代空間大小。-XX:PermSize永久代空間的初始值。-XX:MaxPermSize永久代空間的最大值。

GC 類型配置

配置描述-XX:+UseSerialGC串列垃圾回收器-XX:+UseParallelGC並行垃圾回收器-XX:+UseParNewGC使用 ParNew + Serial Old 垃圾回收器組合-XX:+UseConcMarkSweepGC併發標記掃描垃圾回收器-XX:ParallelCMSThreads=併發標記掃描垃圾回收器 = 為使用的線程數量-XX:+UseG1GCG1 垃圾回收器

輔助配置

配置描述-XX:+PrintGCDetails列印 GC 日誌-Xloggc:<filename>指定 GC 日誌文件名-XX:+HeapDumpOnOutOfMemoryError記憶體溢出時輸出堆快照文件

典型配置

堆大小設置

年輕代的設置很關鍵。

JVM 中最大堆大小有三方面限制:

  1. 相關操作系統的數據模型(32-bt 還是 64-bit)限制;
  2. 系統的可用虛擬記憶體限制;
  3. 系統的可用物理記憶體限制。
整個堆大小 = 年輕代大小 + 年老代大小 + 持久代大小
  • 持久代一般固定大小為 64m。使用 -XX:PermSize 設置。
  • 官方推薦年輕代占整個堆的 3/8。使用 -Xmn 設置。

回收器選擇

JVM 給了三種選擇:串列收集器、並行收集器、併發收集器。

JVM 實戰

分析 GC 日誌

獲取 GC 日誌

獲取 GC 日誌有兩種方式:

  • 使用命令動態查看
  • 在容器中設置相關參數列印 GC 日誌

jstat -gc 統計垃圾回收堆的行為:

jstat -gc 1262
 S0C    S1C     S0U     S1U   EC       EU        OC         OU        PC       PU         YGC    YGCT    FGC    FGCT     GCT
26112.0 24064.0 6562.5  0.0   564224.0 76274.5   434176.0   388518.3  524288.0 42724.7    320    6.417   1      0.398    6.815

也可以設置間隔固定時間來列印:

$ jstat -gc 1262 2000 20

這個命令意思就是每隔 2000ms 輸出 1262 的 gc 情況,一共輸出 20 次

Tomcat 設置示例:

JAVA_OPTS="-server -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m -XX:SurvivorRatio=4
-verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log
-Djava.awt.headless=true
-XX:+PrintGCTimeStamps -XX:+PrintGCDetails
-Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000
-XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15"
  • -Xms2000m -Xmx2000m -Xmn800m -XX:PermSize=64m -XX:MaxPermSize=256m Xms,即為 jvm 啟動時得 JVM 初始堆大小,Xmx 為 jvm 的最大堆大小,xmn 為新生代的大小,permsize 為永久代的初始大小,MaxPermSize 為永久代的最大空間。
  • -XX:SurvivorRatio=4 SurvivorRatio 為新生代空間中的 Eden 區和救助空間 Survivor 區的大小比值,預設是 8,則兩個 Survivor 區與一個 Eden 區的比值為 2:8,一個 Survivor 區占整個年輕代的 1/10。調小這個參數將增大 survivor 區,讓對象儘量在 survitor 區呆長一點,減少進入年老代的對象。去掉救助空間的想法是讓大部分不能馬上回收的數據儘快進入年老代,加快年老代的回收頻率,減少年老代暴漲的可能性,這個是通過將-XX:SurvivorRatio 設置成比較大的值(比如 65536)來做到。
  • -verbose:gc -Xloggc:$CATALINA_HOME/logs/gc.log 將虛擬機每次垃圾回收的信息寫到日誌文件中,文件名由 file 指定,文件格式是平文件,內容和-verbose:gc 輸出內容相同。
  • -Djava.awt.headless=true Headless 模式是系統的一種配置模式。在該模式下,系統缺少了顯示設備、鍵盤或滑鼠。
  • -XX:+PrintGCTimeStamps -XX:+PrintGCDetails 設置 gc 日誌的格式
  • -Dsun.rmi.dgc.server.gcInterval=600000 -Dsun.rmi.dgc.client.gcInterval=600000 指定 rmi 調用時 gc 的時間間隔
  • -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=15 採用併發 gc 方式,經過 15 次 minor gc 後進入年老代

如何分析 GC 日誌

Young GC 回收日誌:

2016-07-05T10:43:18.093+0800: 25.395: [GC [PSYoungGen: 274931K->10738K(274944K)] 371093K->147186K(450048K), 0.0668480 secs] [Times: user=0.17 sys=0.08, real=0.07 secs]

Full GC 回收日誌:

2016-07-05T10:43:18.160+0800: 25.462: [Full GC [PSYoungGen: 10738K->0K(274944K)] [ParOldGen: 136447K->140379K(302592K)] 147186K->140379K(577536K) [PSPermGen: 85411K->85376K(171008K)], 0.6763541 secs] [Times: user=1.75 sys=0.02, real=0.68 secs]

通過上面日誌分析得出,PSYoungGen、ParOldGen、PSPermGen 屬於 Parallel 收集器。其中 PSYoungGen 表示 gc 回收前後年輕代的記憶體變化;ParOldGen 表示 gc 回收前後老年代的記憶體變化;PSPermGen 表示 gc 回收前後永久區的記憶體變化。young gc 主要是針對年輕代進行記憶體回收比較頻繁,耗時短;full gc 會對整個堆記憶體進行回城,耗時長,因此一般儘量減少 full gc 的次數

通過兩張圖非常明顯看出 gc 日誌構成:

OutOfMemory(OOM)分析

OutOfMemory ,即記憶體溢出,是一個常見的 JVM 問題。那麼分析 OOM 的思路是什麼呢?

首先,要知道有三種 OutOfMemoryError:

  • OutOfMemoryError:Java heap space - 堆空間溢出
  • OutOfMemoryError:PermGen space - 方法區和運行時常量池溢出
  • OutOfMemoryError:unable to create new native thread - 線程過多

OutOfMemoryError:PermGen space

OutOfMemoryError:PermGen space 表示方法區和運行時常量池溢出。

原因:

Perm 區主要用於存放 Class 和 Meta 信息的,Class 在被 Loader 時就會被放到 PermGen space,這個區域稱為年老代。GC 在主程式運行期間不會對年老區進行清理,預設是 64M 大小。

當程式程式中使用了大量的 jar 或 class,使 java 虛擬機裝載類的空間不夠,超過 64M 就會報這部分記憶體溢出了,需要加大記憶體分配,一般 128m 足夠。

解決方案:

(1)擴大永久代空間

  • JDK7 以前使用 -XX:PermSize 和 -XX:MaxPermSize 來控制永久代大小。
  • JDK8 以後把原本放在永久代的字元串常量池移出, 放在 Java 堆中(元空間 Metaspace)中,元數據並不在虛擬機中,使用的是本地的記憶體。使用 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 控制元空間大小。
註意:-XX:PermSize 一般設為 64M

(2)清理應用程式中 WEB-INF/lib 下的 jar,用不上的 jar 刪除掉,多個應用公共的 jar 移動到 Tomcat 的 lib 目錄,減少重覆載入。

OutOfMemoryError:Java heap space

OutOfMemoryError:Java heap space 表示堆空間溢出。

原因:JVM 分配給堆記憶體的空間已經用滿了。

問題定位

(1)使用 jmap 或 -XX:+HeapDumpOnOutOfMemoryError 獲取堆快照。 (2)使用記憶體分析工具(visualvm、mat、jProfile 等)對堆快照文件進行分析。 (3)根據分析圖,重點是確認記憶體中的對象是否是必要的,分清究竟是是記憶體泄漏(Memory Leak)還是記憶體溢出(Memory Overflow)。

記憶體泄露

記憶體泄漏是指由於疏忽或錯誤造成程式未能釋放已經不再使用的記憶體的情況。

記憶體泄漏並非指記憶體在物理上的消失,而是應用程式分配某段記憶體後,由於設計錯誤,失去了對該段記憶體的控制,因而造成了記憶體的浪費。

記憶體泄漏隨著被執行的次數越多-最終會導致記憶體溢出。

而因程式死迴圈導致的不斷創建對象-只要被執行到就會產生記憶體溢出。

記憶體泄漏常見幾個情況:

  • 靜態集合類
    • 聲明為靜態(static)的 HashMap、Vector 等集合
    • 通俗來講 A 中有 B,當前只把 B 設置為空,A 沒有設置為空,回收時 B 無法回收-因被 A 引用。

 

  • 監聽器
    • 監聽器被註冊後釋放對象時沒有刪除監聽器

 

  • 物理連接
    • DataSource.getConnection()建立鏈接,必須通過 close()關閉鏈接

 

  • 內部類和外部模塊等的引用
    • 發現它的方式同記憶體溢出,可再加個實時觀察
    • jstat -gcutil 7362 2500 70

 

重點關註:

  • FGC — 從應用程式啟動到採樣時發生 Full GC 的次數。
  • FGCT — 從應用程式啟動到採樣時 Full GC 所用的時間(單位秒)。
  • FGC 次數越多,FGCT 所需時間越多-可非常有可能存在記憶體泄漏。

解決方案

(1)檢查程式,看是否有死迴圈或不必要地重覆創建大量對象。有則改之。

下麵是一個重覆創建記憶體的示例:

public class OOM {
    public static void main(String[] args) {
        Integer sum1=300000;
        Integer sum2=400000;
        OOM oom = new OOM();
        System.out.println("往ArrayList中加入30w內容");
        oom.javaHeapSpace(sum1);
        oom.memoryTotal();
        System.out.println("往ArrayList中加入40w內容");
        oom.javaHeapSpace(sum2);
        oom.memoryTotal();
    }
    public void javaHeapSpace(Integer sum){
        Random random = new Random();  
        ArrayList openList = new ArrayList();
        for(int i=0;i<sum;i++){
            String charOrNum = String.valueOf(random.nextInt(10));
            openList.add(charOrNum);
        }  
    }
    public void memoryTotal(){
        Runtime run = Runtime.getRuntime();
        long max = run.maxMemory();
        long total = run.totalMemory();
        long free = run.freeMemory();
        long usable = max - total + free;
        System.out.println("最大記憶體 = " + max);
        System.out.println("已分配記憶體 = " + total);
        System.out.println("已分配記憶體中的剩餘空間 = " + free);
        System.out.println("最大可用記憶體 = " + usable);
    }
}

 

執行結果:

往ArrayList中加入30w內容
最大記憶體 = 20447232
已分配記憶體 = 20447232
已分配記憶體中的剩餘空間 = 4032576
最大可用記憶體 = 4032576
往ArrayList中加入40w內容
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:2245)
    at java.util.Arrays.copyOf(Arrays.java:2219)
    at java.util.ArrayList.grow(ArrayList.java:242)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:216)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:208)
    at java.util.ArrayList.add(ArrayList.java:440)
    at pers.qingqian.study.seven.OOM.javaHeapSpace(OOM.java:36)
    at pers.qingqian.study.seven.OOM.main(OOM.java:26)
 

(2)擴大堆記憶體空間

使用 -Xms 和 -Xmx 來控制堆記憶體空間大小。

OutOfMemoryError: GC overhead limit exceeded

原因:JDK6 新增錯誤類型,當 GC 為釋放很小空間占用大量時間時拋出;一般是因為堆太小,導致異常的原因,沒有足夠的記憶體。

解決方案:

查看系統是否有使用大記憶體的代碼或死迴圈; 通過添加 JVM 配置,來限制使用記憶體:

<jvm-arg>-XX:-UseGCOverheadLimit</jvm-arg>

 

OutOfMemoryError:unable to create new native thread

原因:線程過多

那麼能創建多少線程呢?這裡有一個公式:

(MaxProcessMemory - JVMMemory - ReservedOsMemory) / (ThreadStackSize) = Number of threads  
MaxProcessMemory 指的是一個進程的最大記憶體  
JVMMemory         JVM記憶體  
ReservedOsMemory  保留的操作系統記憶體  
ThreadStackSize      線程棧的大小

當發起一個線程的創建時,虛擬機會在 JVM 記憶體創建一個 Thread 對象同時創建一個操作系統線程,而這個系統線程的記憶體用的不是 JVMMemory,而是系統中剩下的記憶體: (MaxProcessMemory - JVMMemory - ReservedOsMemory) 結論:你給 JVM 記憶體越多,那麼你能用來創建的系統線程的記憶體就會越少,越容易發生 java.lang.OutOfMemoryError: unable to create new native thread。

CPU 過高

定位步驟:

(1)執行 top -c 命令,找到 cpu 最高的進程的 id

(2)jstack PID 導出 Java 應用程式的線程堆棧信息。

示例:

jstack 6795

"Low Memory Detector" daemon prio=10 tid=0x081465f8 nid=0x7 runnable [0x00000000..0x00000000]  
        "CompilerThread0" daemon prio=10 tid=0x08143c58 nid=0x6 waiting on condition [0x00000000..0xfb5fd798]  
        "Signal Dispatcher" daemon prio=10 tid=0x08142f08 nid=0x5 waiting on condition [0x00000000..0x00000000]  
        "Finalizer" daemon prio=10 tid=0x08137ca0 nid=0x4 in Object.wait() [0xfbeed000..0xfbeeddb8]  

        at java.lang.Object.wait(Native Method)  

        - waiting on <0xef600848> (a java.lang.ref.ReferenceQueue$Lock)  

        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)  

        - locked <0xef600848> (a java.lang.ref.ReferenceQueue$Lock)  

        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)  

        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)  

        "Reference Handler" daemon prio=10 tid=0x081370f0 nid=0x3 in Object.wait() [0xfbf4a000..0xfbf4aa38]  

        at java.lang.Object.wait(Native Method)  

        - waiting on <0xef600758> (a java.lang.ref.Reference$Lock)  

        at java.lang.Object.wait(Object.java:474)  

        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)  

        - locked <0xef600758> (a java.lang.ref.Reference$Lock)  

        "VM Thread" prio=10 tid=0x08134878 nid=0x2 runnable  

        "VM Periodic Task Thread" prio=10 tid=0x08147768 nid=0x8 waiting on condition

 

在列印的堆棧日誌文件中,tid 和 nid 的含義:

nid : 對應的 Linux 操作系統下的 tid 線程號,也就是前面轉化的 16 進位數字
tid: 這個應該是 jvm 的 jmm 記憶體規範中的唯一地址定位

在 CPU 過高的情況下,查找響應的線程,一般定位都是用 nid 來定位的。而如果發生死鎖之類的問題,一般用 tid 來定位。

(3)定位 CPU 高的線程列印其 nid

查看線程下具體進程信息的命令如下:

top -H -p 6735

top - 14:20:09 up 611 days,  2:56,  1 user,  load average: 13.19, 7.76, 7.82
Threads: 6991 total,  17 running, 6974 sleeping,   0 stopped,   0 zombie
%Cpu(s): 90.4 us,  2.1 sy,  0.0 ni,  7.0 id,  0.0 wa,  0.0 hi,  0.4 si,  0.0 st
KiB Mem:  32783044 total, 32505008 used,   278036 free,   120304 buffers
KiB Swap:        0 total,        0 used,        0 free.  4497428 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 6800 root      20   0 27.299g 0.021t   7172 S 54.7 70.1 187:55.61 java
 6803 root      20   0 27.299g 0.021t   7172 S 54.4 70.1 187:52.59 java
 6798 root      20   0 27.299g 0.021t   7172 S 53.7 70.1 187:55.08 java
 6801 root      20   0 27.299g 0.021t   7172 S 53.7 70.1 187:55.25 java
 6797 root      20   0 27.299g 0.021t   7172 S 53.1 70.1 187:52.78 java
 6804 root      20   0 27.299g 0.021t   7172 S 53.1 70.1 187:55.76 java
 6802 root      20   0 27.299g 0.021t   7172 S 52.1 70.1 187:54.79 java
 6799 root      20   0 27.299g 0.021t   7172 S 51.8 70.1 187:53.36 java
 6807 root      20   0 27.299g 0.021t   7172 S 13.6 70.1  48:58.60 java
11014 root      20   0 27.299g 0.021t   7172 R  8.4 70.1   8:00.32 java
10642 root      20   0 27.299g 0.021t   7172 R  6.5 70.1   6:32.06 java
 6808 root      20   0 27.299g 0.021t   7172 S  6.1 70.1 159:08.40 java
11315 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   5:54.10 java
12545 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   6:55.48 java
23353 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   2:20.55 java
24868 root      20   0 27.299g 0.021t   7172 S  3.9 70.1   2:12.46 java
 9146 root      20   0 27.299g 0.021t   7172 S  3.6 70.1   7:42.72 java

 

由此可以看出占用 CPU 較高的線程,但是這些還不高,無法直接定位到具體的類。nid 是 16 進位的,所以我們要獲取線程的 16 進位 ID:

printf "%x\n" 6800
輸出結果:45cd

然後根據輸出結果到 jstack 列印的堆棧日誌中查定位:

"catalina-exec-5692" daemon prio=10 tid=0x00007f3b05013800 nid=0x45cd waiting on condition [0x00007f3ae08e3000]
   java.lang.Thread.State: TIMED_WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000006a7800598> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
        at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)
        at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)
        at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)
        at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:745)

 

免費Java資料需要自己領取,涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高併發分散式等教程,一共30G。
傳送門:


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 配置環境:python 3.6 python編輯器:pycharm 整理成代碼如下: ...
  • 一、AQS概念 1、隊列同步器是用來構建鎖或者其他同步組件的基礎框架,使用一個int型變數代表同步狀態,通過內置的隊列來完成線程的排隊工作。 2、下麵是JDK8文檔中對於AQS的部分介紹 總結來說就是: ①子類通過繼承AQS並實現其抽象方法來管理同步狀態,對於同步狀態的更改通過提供的getState ...
  • 最近項目需要實現根據關鍵字搜索pdf內容,實現思路就是提取pdf文本,然後進行索引。 工具上選擇: IText 4.16之後採用agpl License,不能用作商用,而且轉換中文會有亂碼問題, pdfsharp 採用MIT License,許可權上沒有問題,但是轉換中文也會有亂碼, 最後決定採用xp ...
  • 最近有很多朋友去目前主流的大型互聯網公司面試(阿裡巴巴、京東、美團、滴滴),面試回來之後會發給我一些面試題。有些朋友輕鬆過關,拿到offer,但是有一些是來詢問我答案的。 其實本來真的沒打算寫這篇文章,主要是自己得記憶力不是很好,不像一些記憶力強的人,面試完以後,幾乎能把自己和麵試官的對話都給記下來 ...
  • 1 前言 由於Python的版本眾多,還有Python2和Python3的爭論,因此有些軟體包或第三方庫就容易出現版本不相容的問題。 通過 這個工具,就可以構建一系列 ,然後在每個環境中安裝需要的軟體包(配合 使用),這一系列的環境是相互隔離的。作為一個獨立的環境就不容易出現版本問題,還方便部署。 ...
  • 寫在前面:所有題目都是用python寫的,有一些題目懶得重頭寫,直接用python自帶的功能或庫造好的“輪子” 一、開始之前 1、只出現一次的數字 說明: 示例 1: 示例 2: 2、求眾數 示例 1: 示例 2: 3、搜索二維矩陣 II 示例: 現有矩陣 matrix 如下: [ [1, 4, 7 ...
  • 昨天補充: 編碼: Unicode ; utf-8 ; GBK 關係: 關鍵字:1. continue 終止當前迴圈,進行下一次迴圈 2. break 終止迴圈 題6解法2: 今日內容:Python的開發IDE—Pycharm IDE:Pycharm、eclipse pycharm比較好用點..>> ...
  • thinkphp框架,是一堆代碼(常量,方法,和類)的集合,框架是一個半成品的應用,還包含一些優秀的設計模式。 框架的使用,代碼風格不一樣,維護難,項目生命周期短,功能擴展存在局限,好處為,簡單,快捷,高效,不需要關註底層結構,專註於業務邏輯 zend framework,官方框架,yii框架,美國 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...