偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

【死磕JVM】看完這篇我也會排查JVM內(nèi)存過高了 就是玩兒！

作者：牧小農(nóng)
開發(fā) 前端
如何監(jiān)控JVM，我們可以通過一個案例在了解一些實際當(dāng)中的操作，大家可以看到下面的代碼，下面的代碼只是模擬了當(dāng)中的一個場景，一個風(fēng)險控制的場景，一般銀行或者第三方公司在向一個人發(fā)放貸款的時候，會調(diào)用這個人的征信已經(jīng)還款能力，給出響應(yīng)的評級。

[[403185]]

前言

CPU 是時分的，操作系統(tǒng)里面有很多線程，每個線程的運行時間由CPU決定，CPU會分給每一個線程一個時間片，時間片是一個很短的時間長度，如果在時間片內(nèi)，線程一直占有，就是100%，我們應(yīng)該意識到，CPU運行速度很快(主頻非常高)，除非是密集型耗費CPU的運算，其他類型的任務(wù)都會在小于時間片的時間內(nèi)結(jié)束。

內(nèi)存過高一般有兩種情況：內(nèi)存溢出和內(nèi)存泄露

  • 內(nèi)存溢出： 程序分配的內(nèi)存超過物理機的內(nèi)存大小，導(dǎo)致無法繼續(xù)分配內(nèi)存，出現(xiàn)OOM報錯
  • 內(nèi)存泄露： 不再使用的對象一直占據(jù)著內(nèi)存不釋放，導(dǎo)致這塊內(nèi)存浪費掉，久而久之，內(nèi)存泄露的對象堆積起來，也會導(dǎo)致物理機的內(nèi)存被耗盡，出現(xiàn)OOM報錯

具體操作

如何監(jiān)控JVM，我們可以通過一個案例在了解一些實際當(dāng)中的操作，大家可以看到下面的代碼，下面的代碼只是模擬了當(dāng)中的一個場景，一個風(fēng)險控制的場景，一般銀行或者第三方公司在向一個人發(fā)放貸款的時候，會調(diào)用這個人的征信已經(jīng)還款能力，給出響應(yīng)的評級。

  1. import java.math.BigDecimal; 
  2.  
  3. import java.util.ArrayList; 
  4.  
  5. import java.util.Date; 
  6.  
  7. import java.util.List; 
  8.  
  9. import java.util.concurrent.ScheduledThreadPoolExecutor; 
  10.  
  11. import java.util.concurrent.ThreadPoolExecutor; 
  12.  
  13. import java.util.concurrent.TimeUnit; 
  14.  
  15. public class FullGCTest { 
  16.  
  17. //模擬銀行卡的類 
  18.  
  19. private static class CardInfo { 
  20.  
  21. //小農(nóng)的銀行卡信息記錄 
  22.  
  23. BigDecimal price = new BigDecimal(10000000.0); 
  24.  
  25. String name = "牧小農(nóng)"; 
  26.  
  27. int age = 18; 
  28.  
  29. Date birthdate = new Date(); 
  30.  
  31. public void m() {} 
  32.  
  33. } 
  34.  
  35. //線程池 定時線程池 
  36.  
  37. //50個，然后設(shè)置 拒絕策略 
  38.  
  39. private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50, 
  40.  
  41. new ThreadPoolExecutor.DiscardOldestPolicy()); 
  42.  
  43. public static void main(String[] args) throws Exception { 
  44.  
  45. executor.setMaximumPoolSize(50); 
  46.  
  47. for (;;){ 
  48.  
  49. modelFit(); 
  50.  
  51. Thread.sleep(100); 
  52.  
  53. } 
  54.  
  55. } 
  56.  
  57. /** 
  58.  
  59. * 對銀行卡進行風(fēng)險評估 
  60.  
  61. */ 
  62.  
  63. private static void modelFit(){ 
  64.  
  65. List taskList = getAllCardInfo(); 
  66.  
  67. //拿出每一個信息出來 
  68.  
  69. taskList.forEach(info -> { 
  70.  
  71. // do something 
  72.  
  73. executor.scheduleWithFixedDelay(() -> { 
  74.  
  75. //調(diào)用M方法 
  76.  
  77. info.m(); 
  78.  
  79. }, 2, 3, TimeUnit.SECONDS); 
  80.  
  81. }); 
  82.  
  83. } 
  84.  
  85. private static List getAllCardInfo(){ 
  86.  
  87. List taskList = new ArrayList<>(); 
  88.  
  89. //每次查詢100張卡出來 
  90.  
  91. for (int i = 0; i < 100; i++) { 
  92.  
  93. CardInfo ci = new CardInfo(); 
  94.  
  95. taskList.add(ci); 
  96.  
  97. } 
  98.  
  99. return taskList; 
  100.  
  101. } 
  102.  
  103. } 

程序的設(shè)計其實比較簡單，就是我們用信用卡的案例來進行說明，比如CardInfo就是信用卡類，我們把這個人對應(yīng)的信用卡的記錄都調(diào)用出來，之后做一些自己響應(yīng)的業(yè)務(wù)處理方法來對它進行處理和計算，來看看我們這個模型是否符合modelFit，具體怎么做呢，在應(yīng)用程序中有一個類是CardInfo，有一個方法叫做getAllCardInfo，每次都是拿100個出來，拿100個之后用線程池做計算，線程池用的是 ScheduledThreadPoolExecutor(定時任務(wù))，new出來線程池之后，50個線程池，然后做對應(yīng)的業(yè)務(wù)邏輯處理，會調(diào)用 modelFit()，使用100毫秒模擬業(yè)務(wù)的停頓。

首先我們需要使用javac 命令將Java文件進行編譯

  • javac FullGCTest.java 進行編譯，然后打印GC日志，進行風(fēng)險監(jiān)控
  • 打印GC日志： java -Xms200M -Xmx200M -XX:+PrintGC FullGCTest

怎么知道JVM內(nèi)存過高?

在公司里面，如果遇到了JVM內(nèi)存過高的情況，那么一般是運維團隊首先受到報警信息，然后通知對應(yīng)的開發(fā)人員去查看，那么開發(fā)人員應(yīng)該如何查看，或者怎么樣去排查呢?

1、top 查看進程

受到報警信息后，拿top命令去查詢

  1. [root@root ~]# top 

 

查看內(nèi)存不斷增長，CPU占用率居高不下的。top后你會看到它的PID(31061)。它占比比較高。

2、top -Hp 查看線程

找到CPU占用比較高的進程PID，這里我們以 java 的進程為例 使用命令 top -Hp 31061 ，這個時候它會把這個進程里面所有的線程全部線程都羅列出來嗎，這些都是Java這個進程里面內(nèi)部的一些線程，如下圖所示：

我們會看到每個線程的占比都差不多，偶爾會有某一個線程比較高，在某些線程占得比較高的時候，這個小例子最終會是垃圾回收的線程占得比較高，因為垃圾回收不過來了，所以需要不停的來回回收，每次都回收一點點，實際這種例子里面非常有可能是你業(yè)務(wù)邏輯線程，那一塊的業(yè)務(wù)邏輯線程占比非常高，這是時候就需要用到另外的命令——jstack

3、jstack

當(dāng)我們使用 top -Hp 知道了是哪個線程后，我們下一步就可以使用 jstack命令，比如我們要查看31083這個線程號，31061是我們的進程PID，我們要定位某一個線程cpu的占比會比其他cpu高很多，那么我們就要定位這個線程里面到底是什么樣的問題的時候，就需要把這個線程號(31083)記下來。

因為 jstack 用到的線程號是16進制的，所以我們需要把31083的10進制轉(zhuǎn)換成16進制才可以

特點：

每個線程有自己的線程號碼，里面有線程的狀態(tài)，可以觀察線程是否阻塞，如果長時間的wait和block說明這個線程是有問題的

4、轉(zhuǎn)換16進制

因為Java線程文件中的線程ID是16進制，所以需要將線程ID從十進制轉(zhuǎn)換成十六進制

  1. 命令：echo "obase=16;31083" | bc 

 

5、jstack用法解析

  1. [root@root ~]# jstack 
  2.  
  3. Usage: 
  4.  
  5. jstack [-l]  
  6.  
  7. (to connect to running process) 
  8.  
  9. jstack -F [-m] [-l]  
  10.  
  11. (to connect to a hung process) 
  12.  
  13. jstack [-m] [-l]  
  14.  
  15. (to connect to a core file) 
  16.  
  17. jstack [-m] [-l] [server_id@] 
  18.  
  19. (to connect to a remote debug server) 
  20.  
  21. Options: 
  22.  
  23. -F to force a thread dump. Use when jstack does not respond (process is hung) 
  24.  
  25. -m to print both java and native frames (mixed mode) 
  26.  
  27. -l long listing. Prints additional information about locks 
  28.  
  29. -h or -help to print this help message 

6、jstack查看輸出

我們也可以用 jps或者java ps -ef| java 來查看Java進程，這里我們用jps來查看

  1. [root@root ~]# jps 

 

  1. [root@root ~]# jstack 31061 

  1. "pool-1-thread-3" #10 prio=5 os_prio=0 tid=0x00007f3568105800 nid=0x7961 waiting on condition [0x00007f35455cf000] 
  2.    java.lang.Thread.State: WAITING (parking) 
  3.         at sun.misc.Unsafe.park(Native Method) 
  4.         - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
  5.         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
  6.         at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) 
  7.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088) 
  8.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) 
  9.         at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) 
  10.         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
  11.         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
  12.         at java.lang.Thread.run(Thread.java:748) 
  13. "pool-1-thread-2" #9 prio=5 os_prio=0 tid=0x00007f3568103800 nid=0x7960 waiting on condition [0x00007f35456d0000] 
  14.    java.lang.Thread.State: WAITING (parking) 
  15.         at sun.misc.Unsafe.park(Native Method) 
  16.         - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
  17.         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
  18.         at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) 
  19.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088) 
  20.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) 
  21.         at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) 
  22.         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
  23.         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
  24.         at java.lang.Thread.run(Thread.java:748) 
  25.  
  26. "pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f3568102000 nid=0x795f waiting on condition [0x00007f35457d1000] 
  27.    java.lang.Thread.State: WAITING (parking) 
  28.         at sun.misc.Unsafe.park(Native Method) 
  29.         - parking to wait for  <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
  30.         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 
  31.         at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) 
  32.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088) 
  33.         at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809) 
  34.         at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074) 
  35.         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134) 
  36.         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
  37.         at java.lang.Thread.run(Thread.java:748) 
  38.  
  39. "Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f35680b4000 nid=0x795d runnable [0x0000000000000000] 
  40.    java.lang.Thread.State: RUNNABLE 
  41.  
  42. "C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f35680b1000 nid=0x795c waiting on condition [0x0000000000000000] 
  43.    java.lang.Thread.State: RUNNABLE 
  44.  
  45. "C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f35680af000 nid=0x795b waiting on condition [0x0000000000000000] 
  46.    java.lang.Thread.State: RUNNABLE 
  47.  
  48. "Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f35680ad800 nid=0x795a runnable [0x0000000000000000] 
  49.    java.lang.Thread.State: RUNNABLE 
  50.  
  51. "Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f356807c800 nid=0x7959 in Object.wait() [0x00007f3558301000] 
  52.    java.lang.Thread.State: WAITING (on object monitor) 
  53.         at java.lang.Object.wait(Native Method) 
  54.         - waiting on <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock) 
  55.         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144) 
  56.         - locked <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock) 
  57.         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165) 
  58.         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216) 
  59.  
  60. "Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f3568077800 nid=0x7958 in Object.wait() [0x00007f3558402000] 
  61.    java.lang.Thread.State: WAITING (on object monitor) 
  62.         at java.lang.Object.wait(Native Method) 
  63.         - waiting on <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock) 
  64.         at java.lang.Object.wait(Object.java:502) 
  65.         at java.lang.ref.Reference.tryHandlePending(Reference.java:191) 
  66.         - locked <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock) 
  67.         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153) 
  68.  
  69. "main" #1 prio=5 os_prio=0 tid=0x00007f3568009800 nid=0x7956 waiting on condition [0x00007f356ed59000] 
  70.    java.lang.Thread.State: TIMED_WAITING (sleeping) 
  71.         at java.lang.Thread.sleep(Native Method) 
  72.         at FullGCTest.main(FullGCTest.java:35) 
  73.  
  74. "VM Thread" os_prio=0 tid=0x00007f356806e000 nid=0x7957 runnable  
  75.  
  76. "VM Periodic Task Thread" os_prio=0 tid=0x00007f35680b7000 nid=0x795e waiting on condition  
  77.  
  78. JNI global references: 205 

 

 通過thread dump分析線程狀態(tài)

大多數(shù)情況下會基于thead dump 分析當(dāng)前各個線程的運行情況，如是否存在死鎖，是否存在一個線程長時間持有鎖不釋放等等

在dump中，線程一般存在如下幾種狀態(tài)：1、RUNNABLE，線程處于執(zhí)行中 2、BLOCKED，線程被阻塞 3、WAITING，線程正在等待

  • locked <0x000000076bf62208> 說明線程 對地址為0x000000076bf62208對象進行了加鎖;waiting to lock <0x000000076bf62208> 說明線程 在等待地址為0x000000076bf62208對象上的鎖;waiting for monitor entry [0x000000001e21f000]說明線程 是通過synchronized關(guān)鍵字進入了監(jiān)視器的臨界區(qū)，并處于"Entry Set"隊列，等待monitor;waiting on <0x0000000088ca3310> (a java.lang.Object)等待鎖的釋放
  • 假如有一個進程中有100個線程，很多線程都在waiting on 某一把鎖，然后線程不該阻塞的被阻塞了，該結(jié)束的沒結(jié)束掉，一定要找到哪個線程持有這把鎖 ，我們可以搜索 jstack dump 的信息，找到 <0X...> 的信息，看哪個線程只有了這把鎖，一般這個線程狀態(tài)是RUNNABLE，表示這個線程正在運行但是一直持有這把鎖不釋放，那么就會導(dǎo)致整個線程的死鎖

7、jstack分析死鎖

  1. public class TestDeadLock { 
  2.  
  3. private static Object obj1 = new Object(); 
  4.  
  5. private static Object obj2 = new Object(); 
  6.  
  7. public static void main(String[] args) { 
  8.  
  9. new Thread(new Thread1()).start(); 
  10.  
  11. new Thread(new Thread2()).start(); 
  12.  
  13. } 
  14.  
  15. private static class Thread1 implements Runnable { 
  16.  
  17. @Override 
  18.  
  19. public void run() { 
  20.  
  21. synchronized (obj1) { 
  22.  
  23. System.out.println("Thread1 拿到了 obj1 的鎖!"); 
  24.  
  25. try {// 停頓2秒的意義在于，讓Thread2線程拿到obj2的鎖 
  26.  
  27. Thread.sleep(2000); 
  28.  
  29. } catch (InterruptedException e) { 
  30.  
  31. e.printStackTrace(); 
  32.  
  33. } 
  34.  
  35. synchronized (obj2) { 
  36.  
  37. System.out.println("Thread1 拿到了 obj2 的鎖!"); 
  38.  
  39. } 
  40.  
  41. } 
  42.  
  43. } 
  44.  
  45. } 
  46.  
  47. private static class Thread2 implements Runnable { 
  48.  
  49. @Override 
  50.  
  51. public void run() { 
  52.  
  53. synchronized (obj2) { 
  54.  
  55. System.out.println("Thread2 拿到了 obj2 的鎖!"); 
  56.  
  57. try { 
  58.  
  59. // 停頓2秒的意義在于，讓Thread1線程拿到obj1的鎖 
  60.  
  61. Thread.sleep(2000); 
  62.  
  63. } catch (Exception e) { 
  64.  
  65. e.printStackTrace(); 
  66.  
  67. } 
  68.  
  69. synchronized (obj1) { 
  70.  
  71. System.out.println("Thread2 拿到了obj1的鎖!"); 
  72.  
  73. } 
  74.  
  75. } 
  76.  
  77. } 
  78.  
  79. } 
  80.  
  81. } 

 

通過命令查看分析日志

  1. [root@root fuccGC]# jps 
  2.  
  3. 485 Bootstrap 
  4.  
  5. 9877 Jps 
  6.  
  7. 10629 QuorumPeerMain 
  8.  
  9. 9846 TestDeadLock 
  10.  
  11. [root@root fuccGC]# jstack 9846 

 

內(nèi)存監(jiān)控工具的使用

我們可以使用jvm自帶的命令去進行監(jiān)控GC的信息： jinfo pid： 這個命令就是把這個進程的一些詳細信息列出來

  1. [root@root ~]# jinfo 9846 

這個只是有幫助，但是幫助不是特別大，大家只要記住有這個命令就行，不做深入了解

jstat -gc pid 1000： 這個就是每一秒鐘將GC的日志打印出來，動態(tài) 觀察GC情況/閱讀GC日志發(fā)現(xiàn)頻繁GC等等，但是這個信息看起來不是很直觀，能夠分析出來的東西也不多，所以一般使用的也不是很多

我們用的最多的還是通過工具去查看，比如 jconsole/jvisualvm

1、 jconsole

這兩個是JDK自帶的一個工具，也是 一個圖形界面的工具，只要你裝了JDK就有這兩個工具，可以從本機去跟蹤遠程服務(wù)器上的一個進程，作為Linux服務(wù)器，很少有人會裝圖形界面，如下圖所示：

在我們程序啟動的時候要加入?yún)?shù)：

  1. java -Djava.rmi.server.hostname=101.XX.XXX.XX -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=8080 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.rmi.port=8080 FullGCTes 

 

基本情況如下，我們就可以監(jiān)控到我們遠程服務(wù)器上面的內(nèi)存信息

2、 jvisualvm

雙擊 jvisualvm

選擇遠程-點擊文件按鈕

選擇添加JMX連接

輸入我們的地址和賬號密碼就可以登錄了

這樣就可以查看我們遠程服務(wù)的內(nèi)存信息了

在這里我們就知道怎么定位問題了，哪一個類占用了多少內(nèi)存，就會顯示出來，點擊抽樣器，內(nèi)存，之后就會對遠程的那臺機器的JAVA進程內(nèi)存，在圖形化界面中顯示，有多少個類，占用了多少個字節(jié)，這樣我們就可以具體定位到是哪個類有問題了

面試中如何回答定位內(nèi)存溢出(OOM)

如果面試官我們?nèi)绾味ㄎ籓OM的問題，但是我們不能回答用圖形界面，因為作為一個服務(wù)來講，在不斷的運行，當(dāng)我們開一個JMX服務(wù)的時候，會形象服務(wù)本來的運行效率，那我們已經(jīng)上線的系統(tǒng)不用圖形化用什么?還有一個叫Jprofiler是最好用的圖形界面，但是這個是收費的，所以一般用不到，

如果不用圖形界面那我們用什么，我們可以用 cmdline、arthas這兩個 圖形界面用在什么地方呢?用在測試上，測試的時候進行監(jiān)控~

如果已經(jīng)上線的項目，我們不用圖形界面可以用什么呢?我們可以用Jmap

jmap

  1. [root@root~]#jmap-histo19086|head-20  

它就會把我們的內(nèi)存信息打印出來，雖然沒有圖形化界面方便，但是里面的信息也足夠我們?nèi)ビ^察和定位問題了

線上系統(tǒng)，內(nèi)存特別大，jmap執(zhí)行期間會對進程產(chǎn)生很大影響，甚至卡頓(電商不適合)

  1. 設(shè)定了參數(shù)HeapDump，OOM的時候會自動產(chǎn)生堆轉(zhuǎn)儲文件( java-Xms20M-Xmx20M-XX:+UseParallelGC-XX:+HeapDumpOnOutOfMemoryErrorFullGCTest)
  2. 很多服務(wù)器備份(高可用)，停掉這臺服務(wù)器對其他服務(wù)器不影響
  3. 下期講解，哈哈哈

 

責(zé)任編輯：姜華 來源： 牧小農(nóng)
JVM排查JVM內(nèi)存過高技術(shù)
相關(guān)推薦

2021-06-01 09:29:43

ArthasJVM內(nèi)存

2021-06-03 08:32:18

JVM調(diào)優(yōu)虛擬機

2021-02-25 07:21:00

JVMJavaava虛擬機

2021-05-25 09:56:42

Jvm類加載機制Java

2021-02-28 11:58:33

JVM機制語言

2025-06-16 07:40:00

2021-06-09 07:56:51

JvmJVM面試題Java

2019-07-10 15:15:23

JVM虛擬機Java

2019-01-30 13:44:34

JVM內(nèi)存服務(wù)器

2021-03-16 05:44:26

JVM面試題運行時數(shù)據(jù)

2018-07-31 14:03:09

JVM內(nèi)存數(shù)據(jù)

2017-09-20 08:48:09

JVM內(nèi)存結(jié)構(gòu)

2021-06-16 00:57:16

JVM加載機制

2022-07-03 20:31:59

JVMJava虛擬機

2012-01-11 10:45:57

JavaJVM

2024-12-04 16:44:51

2023-11-19 23:29:22

Heap DumpJava

2019-04-29 14:23:46

Java服務(wù)器CPU

2010-09-26 16:42:04

JVM內(nèi)存組成JVM垃圾回收

2021-11-30 05:45:16

固態(tài)硬盤總線接口
點贊
收藏

51CTO技術(shù)棧公眾號