CPU 是時分的,操做系統裏面有不少線程,每一個線程的運行時間由CPU決定,CPU會分給每個線程一個時間片,時間片是一個很短的時間長度,若是在時間片內,線程一直佔有,就是100%,咱們應該意識到,CPU運行速度很快(主頻很是高),除非是密集型耗費CPU的運算,其餘類型的任務都會在小於時間片的時間內結束。java
內存太高通常有兩種狀況:內存溢出和內存泄露面試
如何監控JVM,咱們能夠經過一個案例在瞭解一些實際當中的操做,你們能夠看到下面的代碼,下面的代碼只是模擬了當中的一個場景,一個風險控制的場景,通常銀行或者第三方公司在向一我的發放貸款的時候,會調用這我的的徵信已經還款能力,給出響應的評級。服務器
import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;
import java.util.concurrent.ScheduledThreadPoolExecutor;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;
public class FullGCTest {
//模擬銀行卡的類
private static class CardInfo {
//小農的銀行卡信息記錄
BigDecimal price = new BigDecimal(10000000.0);
String name = "牧小農";
int age = 18;
Date birthdate = new Date();
public void m() {}
}
//線程池 定時線程池
//50個,而後設置 拒絕策略
private static ScheduledThreadPoolExecutor executor = new ScheduledThreadPoolExecutor(50,
new ThreadPoolExecutor.DiscardOldestPolicy());
public static void main(String[] args) throws Exception {
executor.setMaximumPoolSize(50);
for (;;){
modelFit();
Thread.sleep(100);
}
}
/** * 對銀行卡進行風險評估 */
private static void modelFit(){
List<CardInfo> taskList = getAllCardInfo();
//拿出每個信息出來
taskList.forEach(info -> {
// do something
executor.scheduleWithFixedDelay(() -> {
//調用M方法
info.m();
}, 2, 3, TimeUnit.SECONDS);
});
}
private static List<CardInfo> getAllCardInfo(){
List<CardInfo> taskList = new ArrayList<>();
//每次查詢100張卡出來
for (int i = 0; i < 100; i++) {
CardInfo ci = new CardInfo();
taskList.add(ci);
}
return taskList;
}
}
複製代碼
程序的設計其實比較簡單,就是咱們用信用卡的案例來進行說明,好比CardInfo就是信用卡類,咱們把這我的對應的信用卡的記錄都調用出來,以後作一些本身響應的業務處理方法來對它進行處理和計算,來看看咱們這個模型是否符合modelFit,具體怎麼作呢,在應用程序中有一個類是CardInfo,有一個方法叫作getAllCardInfo,每次都是拿100個出來,拿100個以後用線程池作計算,線程池用的是ScheduledThreadPoolExecutor (定時任務)
,new出來線程池以後,50個線程池,而後作對應的業務邏輯處理,會調用 modelFit(),使用100毫秒模擬業務的停頓。markdown
首先咱們須要使用javac 命令將Java文件進行編譯 javac FullGCTest.java
進行編譯,而後打印GC日誌,進行風險監控多線程
打印GC日誌:java -Xms200M -Xmx200M -XX:+PrintGC FullGCTest
運維
在公司裏面,若是遇到了JVM內存太高的狀況,那麼通常是運維團隊首先受到報警信息,而後通知對應的開發人員去查看,那麼開發人員應該如何查看,或者怎麼樣去排查呢?jvm
受到報警信息後,拿top命令去查詢ide
[root@root ~]# top
工具
查看內存不斷增加,CPU佔用率居高不下的。top後你會看到它的PID(31061)。它佔比比較高。測試
找到CPU佔用比較高的進程PID,這裏咱們以 java 的進程爲例 使用命令 top -Hp 31061
,這個時候它會把這個進程裏面全部的線程所有線程都羅列出來嗎,這些都是Java這個進程裏面內部的一些線程,以下圖所示:
咱們會看到每一個線程的佔比都差很少,偶爾會有某一個線程比較高,在某些線程佔得比較高的時候,這個小例子最終會是垃圾回收的線程佔得比較高,由於垃圾回收不過來了,因此須要不停的來回回收,每次都回收一點點,實際這種例子裏面很是有多是你業務邏輯線程,那一塊的業務邏輯線程佔比很是高,這是時候就須要用到另外的命令——jstack
當咱們使用 top -Hp 知道了是哪一個線程後,咱們下一步就可使用 jstack
命令,好比咱們要查看31083這個線程號,31061是咱們的進程PID,咱們要定位某一個線程cpu的佔比會比其餘cpu高不少,那麼咱們就要定位這個線程裏面究竟是什麼樣的問題的時候,就須要把這個線程號(31083)記下來。
由於 jstack 用到的線程號是16進制的,因此咱們須要把31083的10進制轉換成16進制才能夠
特色:
由於Java線程文件中的線程ID是16進制,因此須要將線程ID從十進制轉換成十六進制 命令:echo "obase=16;31083" | bc
[root@root ~]# jstack
Usage:
jstack [-l] <pid>
(to connect to running process)
jstack -F [-m] [-l] <pid>
(to connect to a hung process)
jstack [-m] [-l] <executable> <core>
(to connect to a core file)
jstack [-m] [-l] [server_id@]<remote server IP or hostname>
(to connect to a remote debug server)
Options:
-F to force a thread dump. Use when jstack <pid> does not respond (process is hung) -m to print both java and native frames (mixed mode) -l long listing. Prints additional information about locks -h or -help to print this help message 複製代碼
咱們也能夠用 jps或者java ps -ef| java
來查看Java進程,這裏咱們用jps來查看
[root@root ~]# jps
[root@root ~]# jstack 31061
"pool-1-thread-3" #10 prio=5 os_prio=0 tid=0x00007f3568105800 nid=0x7961 waiting on condition [0x00007f35455cf000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-2" #9 prio=5 os_prio=0 tid=0x00007f3568103800 nid=0x7960 waiting on condition [0x00007f35456d0000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"pool-1-thread-1" #8 prio=5 os_prio=0 tid=0x00007f3568102000 nid=0x795f waiting on condition [0x00007f35457d1000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f8a81148> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f35680b4000 nid=0x795d runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f35680b1000 nid=0x795c waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f35680af000 nid=0x795b waiting on condition [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f35680ad800 nid=0x795a runnable [0x0000000000000000]
java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f356807c800 nid=0x7959 in Object.wait() [0x00007f3558301000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- locked <0x00000000f8a86b38> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x00007f3568077800 nid=0x7958 in Object.wait() [0x00007f3558402000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- locked <0x00000000f8a86cf0> (a java.lang.ref.Reference$Lock)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"main" #1 prio=5 os_prio=0 tid=0x00007f3568009800 nid=0x7956 waiting on condition [0x00007f356ed59000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at FullGCTest.main(FullGCTest.java:35)
"VM Thread" os_prio=0 tid=0x00007f356806e000 nid=0x7957 runnable
"VM Periodic Task Thread" os_prio=0 tid=0x00007f35680b7000 nid=0x795e waiting on condition
JNI global references: 205
複製代碼
經過thread dump分析線程狀態
大多數狀況下會基於thead dump 分析當前各個線程的運行狀況,如是否存在死鎖,是否存在一個線程長時間持有鎖不釋放等等
在dump中,線程通常存在以下幾種狀態: 一、RUNNABLE,線程處於執行中 二、BLOCKED,線程被阻塞 三、WAITING,線程正在等待
locked <0x000000076bf62208>
說明線程 對地址爲0x000000076bf62208
對象進行了加鎖; waiting to lock <0x000000076bf62208>
說明線程 在等待地址爲0x000000076bf62208
對象上的鎖; waiting for monitor entry [0x000000001e21f000]
說明線程 是經過synchronized關鍵字進入了監視器的臨界區,並處於"Entry Set"隊列,等待monitor; waiting on <0x0000000088ca3310> (a java.lang.Object)
等待鎖的釋放
假若有一個進程中有100個線程,不少線程都在waiting on 某一把鎖,而後線程不應阻塞的被阻塞了,該結束的沒結束掉,必定要找到哪一個線程持有這把鎖 ,咱們能夠搜索 jstack dump 的信息,找到<0X...>
的信息,看哪一個線程只有了這把鎖,通常這個線程狀態是RUNNABLE,表示這個線程正在運行可是一直持有這把鎖不釋放,那麼就會致使整個線程的死鎖
public class TestDeadLock {
private static Object obj1 = new Object();
private static Object obj2 = new Object();
public static void main(String[] args) {
new Thread(new Thread1()).start();
new Thread(new Thread2()).start();
}
private static class Thread1 implements Runnable {
@Override
public void run() {
synchronized (obj1) {
System.out.println("Thread1 拿到了 obj1 的鎖!");
try {// 停頓2秒的意義在於,讓Thread2線程拿到obj2的鎖
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (obj2) {
System.out.println("Thread1 拿到了 obj2 的鎖!");
}
}
}
}
private static class Thread2 implements Runnable {
@Override
public void run() {
synchronized (obj2) {
System.out.println("Thread2 拿到了 obj2 的鎖!");
try {
// 停頓2秒的意義在於,讓Thread1線程拿到obj1的鎖
Thread.sleep(2000);
} catch (Exception e) {
e.printStackTrace();
}
synchronized (obj1) {
System.out.println("Thread2 拿到了obj1的鎖!");
}
}
}
}
}
複製代碼
經過命令查看分析日誌
[root@root fuccGC]# jps
485 Bootstrap
9877 Jps
10629 QuorumPeerMain
9846 TestDeadLock
[root@root fuccGC]# jstack 9846
複製代碼
咱們可使用jvm自帶的命令去進行監控GC的信息: jinfo pid: 這個命令就是把這個進程的一些詳細信息列出來 [root@root ~]# jinfo 9846
這個只是有幫助,可是幫助不是特別大,你們只要記住有這個命令就行,不作深刻了解 jstat -gc pid 1000: 這個就是每一秒鐘將GC的日誌打印出來,動態 觀察GC狀況/閱讀GC日誌發現頻繁GC等等,可是這個信息看起來不是很直觀,可以分析出來的東西也很少,因此通常使用的也不是不少
咱們用的最多的仍是經過工具去查看,好比 jconsole/jvisualvm
這兩個是JDK自帶的一個工具,也是 一個圖形界面的工具,只要你裝了JDK就有這兩個工具,能夠從本機去跟蹤遠程服務器上的一個進程,做爲Linux服務器,不多有人會裝圖形界面,以下圖所示:
在咱們程序啓動的時候要加入參數:
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 FullGCTest
複製代碼
基本狀況以下,咱們就能夠監控到咱們遠程服務器上面的內存信息
雙擊 jvisualvm
選擇遠程-點擊文件按鈕
選擇添加JMX鏈接
輸入咱們的地址和帳號密碼就能夠登陸了
這樣就能夠查看咱們遠程服務的內存信息了
在這裏咱們就知道怎麼定位問題了,哪個類佔用了多少內存,就會顯示出來,點擊抽樣器,內存,以後就會對遠程的那臺機器的JAVA進程內存,在圖形化界面中顯示,有多少個類,佔用了多少個字節,這樣咱們就能夠具體定位到是哪一個類有問題了
若是面試官咱們如何定位OOM的問題,可是咱們不能回答用圖形界面,由於做爲一個服務來說,在不斷的運行,當咱們開一個JMX服務的時候,會形象服務原本的運行效率,那咱們已經上線的系統不用圖形化用什麼?還有一個叫Jprofiler是最好用的圖形界面,可是這個是收費的,因此通常用不到,
若是不用圖形界面那咱們用什麼,咱們能夠用 cmdline、arthas這兩個 圖形界面用在什麼地方呢?用在測試上,測試的時候進行監控~
若是已經上線的項目,咱們不用圖形界面能夠用什麼呢?咱們能夠用Jmap
[root@root ~]# jmap -histo 19086 | head -20
它就會把咱們的內存信息打印出來,雖然沒有圖形化界面方便,可是裏面的信息也足夠咱們去觀察和定位問題了
線上系統,內存特別大,jmap執行期間會對進程產生很大影響,甚至卡頓(電商不適合)
java -Xms20M -Xmx20M -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError FullGCTest
)今天的JVM課程就到這裏了,原創不易,你們記得一鍵三連~,點贊/收藏過百,我就是懷雙胞胎也出下一篇。
我是牧小農,怕什麼真理無窮,進一步有進一步的歡喜,你們加油!!!