當前位置：首頁 > 运维知识 > linux >内容正文

linux

linux at java,Linux-Tutorial/Java-bin.md at master · linsanityHuang/Linux-Tutorial · GitHub

發布時間：2023/12/4 linux 47 豆豆

生活随笔收集整理的這篇文章主要介紹了 linux at java,Linux-Tutorial/Java-bin.md at master · linsanityHuang/Linux-Tutorial · GitHub 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Java bin 目錄下的工具

JVM 內存結構

運行時數據區(JVM 規范)

VM 棧(JVM 虛擬機棧)

是線程私有的，它的生命周期和線程相同。它描述的是 Java 方法執行的內存模式。

Java 堆區(Heap)

是 Java 虛擬機所管理的內存中最大的一塊。是被所有線程共享的一塊內存區域，在虛擬機啟動時候創建。用于存放對象實例。

方法區(Method Area)

也是各個線程共享的內存區域，用于存儲已被虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。

雖然在 JVM 規范上是描述為堆的一個邏輯部分，但是它有一個別名：Non-Heap(非堆)，獨立于堆區之外的。JDK8 它是：Metaspace 區

Metaspace：主要存放：Class、Package、Method、Field、字節碼、常量池、符號引用等等

方法區里面有一個：運行時常量池(Run-Time Constant Pool)，用于存放編譯期生成的各種字面量和符號應用，在類加載后進入該池存放。

本地方法棧(Native Method Stacks)

與虛擬機棧所發揮的作用類似，之間的區別：

虛擬機棧是為虛擬機執行 Java 方法(也就是字節碼)服務

本地方法棧是為了虛擬機使用到 Native 方法服務。

JDK8 真實內存結構(HotSpot)

HotSpot--Java HotSpot Performance Engine，是 Java 虛擬機的一個實現，目前是 Oracle 在維護和發布。

JDK8 HotSpot 的堆內存區域結構

組成：Eden + Surviver(S0 + S1) + Old

對象生命周期：Eden > Surviver(S0 + S1) > Old

Eden:該區域是最主要的剛創建的對象的內存分配區域，絕大多數對象都會被創建到這里(除了部分大對象通過內存擔保機制創建到Old區域，默認大對象都是能夠存活較長時間的)，該區域的對象大部分都是短時間都會死亡的，故垃圾回收器針對該部分主要采用標記整理算法了回收該區域。

Surviver:該區域也是屬于新生代的區域，該區域是將在Eden中未被清理的對象存放到該區域中，該區域分為兩塊區域，采用的是復制算法，每次只使用一塊，Eden與Surviver區域的比例是8:1，是根據大量的業務運行總結出來的規律。

Old:該區域是屬于老年代，一般能夠在Surviver中沒有被清除出去的對象才會進入到這塊區域，該區域主要是采用標記清除算法。

總結：java堆的垃圾回收是垃圾回收器最主要的光顧對象，整體采用分代收集的策略，對不同區域結合其特點采用不同的垃圾收集算法。我們在編程中也應該關注這一塊區域，盡量不適用大對象，盡可能的創建局部對象，使用過后確定廢棄不用的對象及時斷開引用，盡量避免使用循環的對象引用(可達性分析也是比較消耗資源的)等等。

JVM內存區域的詳解圖

更多這類文章

頻繁GC問題或內存溢出排查流程

使用 jps，查看線程ID，假設 PID 為 12011

使用 jstat -gc PID 250 20，查看gc情況，一般比較關注PERM區的情況，查看GC的增長情況。

使用 jstat -gccause PID：額外輸出上次GC原因

使用 jmap -dump:format=b,file=/opt/myHeapDumpFileName 12011，生成堆轉儲文件

使用 jhat 或者可視化工具(Eclipse Memory Analyzer 、IBM HeapAnalyzer)分析堆情況。

結合代碼解決內存溢出或泄露問題。

死鎖問題

使用 jps查看線程ID，假設 PID 為 12011

使用 jstack 12011 查看線程情況

jps

顯示當前所有 java 進程 pid 的命令

16470 Jps

12011 Bootstrap

jps -v 跟：ps -ef|grep java 主要輸出內容一樣

12011 是我這邊的一個 java 應用的 pid，下面的其他命令都是自己與此應用進行分析的

jstat(重要)

顯示進程中的類裝載、內存、垃圾收集、JIT編譯等運行數據。

查看類加載信息：jstat -class PID

垃圾回收統計

jstat -gc PID 250 10，每250毫秒查詢一次，一共查詢10次。

S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT

34944.0 34944.0 1006.5 0.0 279616.0 235729.8 699072.0 12407.5 20736.0 20145.5 2560.0 2411.8 6 0.392 0 0.000 0.392

列含義說明：

**34944.0 表示 34M 大小，235729.8 表示 235M **

SO + S1 + Eden = young 區

-S0C 年輕代中第一個survivor(幸存區)的容量 (字節)

-S1C 年輕代中第二個survivor(幸存區)的容量 (字節)

-S0U 年輕代中第一個survivor(幸存區)目前已使用空間 (字節) (字母 U 表示 used)

-S1U 年輕代中第二個survivor(幸存區)目前已使用空間 (字節) (字母 U 表示 used)

-EC 年輕代中Eden(伊甸園)的容量 (字節)

-EU 年輕代中Eden(伊甸園)目前已使用空間 (字節)

OC + OU = old 區

-OC Old代的容量 (字節)

-OU Old代目前已使用空間 (字節)

MC + MU = Metaspace 區

MC 方法區大小

MU 方法區使用大小

其他

CCSC 壓縮類空間大小

CCSU 壓縮類空間使用大小

YGC 年輕代垃圾回收次數

YGCT 年輕代垃圾回收消耗時間

FGC 老年代垃圾回收次數

FGCT 老年代垃圾回收消耗時間

GCT 垃圾回收消耗總時間

堆內存統計

jstat -gccapacity 12011 250 10，查詢進程 12011 VM內存中三代(young,old,perm)對象的使用和占用大小，每250毫秒查詢一次，一共查詢10次。

NGCMN NGCMX NGC S0C S1C EC OGCMN OGCMX OGC OC MCMN MCMX MC CCSMN CCSMX CCSC YGC FGC

349504.0 1398080.0 349504.0 34944.0 34944.0 279616.0 699072.0 2796224.0 699072.0 699072.0 0.0 1067008.0 20736.0 0.0 1048576.0 2560.0 6 0

列含義說明：

NGCMN 年輕代(young)中初始化(最小)的大小(字節)

NGCMX 年輕代(young)的最大容量 (字節)

NGC 年輕代(young)中當前的容量 (字節)

S0C 年輕代中第一個survivor(幸存區)的容量 (字節)

S1C 年輕代中第二個survivor(幸存區)的容量 (字節)

EC 年輕代中Eden(伊甸園)的容量 (字節)

OGCMN old代中初始化(最小)的大小 (字節)

OGCMX old代的最大容量(字節)

OGC old代當前新生成的容量 (字節)

OC Old代的容量 (字節)

MCMN 最小元數據容量

MCMX 最大元數據容量

MC 當前元數據空間大小

CCSMN 最小壓縮類空間大小

CCSMX 最大壓縮類空間大小

CCSC 當前壓縮類空間大小

YGC 年輕代gc次數，從應用程序啟動到采樣時年輕代中gc次數

FGC 老年代GC次數，從應用程序啟動到采樣時old代(全gc = Full gc次數)gc次數

gcutil

使用：jstat -gcutil PID 3000 10：

正常情況結果應該是這樣的：

S0 S1 E O M CCS YGC YGCT FGC FGCT GCT

0.00 0.00 67.63 38.09 78.03 68.82 124 0.966 5 0.778 1.744

0.00 0.00 67.68 38.09 78.03 68.82 124 0.966 5 0.778 1.744

0.00 0.00 67.71 38.09 78.03 68.82 124 0.966 5 0.778 1.744

S0：SO 當前使用比例

S1：S1 當前使用比例

E：Eden 區使用比例(百分比)(異常的時候，這里可能會接近 100%)

O：old 區使用比例(百分比)(異常的時候，這里可能會接近 100%)

M：Metaspace 區使用比例(百分比)(異常的時候，這里可能會接近 100%)

CCS：壓縮使用比例

YGC：年輕代垃圾回收次數

FGC：老年代垃圾回收次數

FGCT：老年代垃圾回收消耗時間(Full gc耗時)(單位秒)

GCT：垃圾回收消耗總時間(單位秒)

異常的時候每次 Full GC 時間也可能非常長，每次時間計算公式=FGCT值/FGC指)

在 YGC 之前年輕代 = eden + S1；YGC 之后，年輕代 = eden + S0。

如果看到 YGC 之后 old 區空間沒變，表示此次 YGC，沒有對象晉升到 old 區

jmap

生成堆轉儲快照(heap dump)

heap dump 主要記錄了在某一時刻JVM堆中對象使用的情況，即某個時刻JVM堆的快照，是一個二進制文件，主要用于分析哪些對象占用了太對的堆空間，從而發現導致內存泄漏的對象。

堆Dump是反應Java堆使用情況的內存鏡像，其中主要包括系統信息、虛擬機屬性、完整的線程Dump、所有類和對象的狀態等。一般，在內存不足、GC異常等情況下，我們就會懷疑有內存泄露。這個時候我們就可以制作堆Dump來查看具體情況，分析原因。

常見內存錯誤：

outOfMemoryError 年老代內存不足。

outOfMemoryError:PermGen Space 永久代內存不足。

outOfMemoryError:GC overhead limit exceed 垃圾回收時間占用系統運行時間的98%或以上。

jmap -heap 12011，查看指定進程堆(heap)使用情況

Attaching to process ID 12011, please wait...

Debugger attached successfully.

Server compiler detected.

JVM version is 25.151-b12

using thread-local object allocation.

Mark Sweep Compact GC

Heap Configuration:

MinHeapFreeRatio = 40

MaxHeapFreeRatio = 70

MaxHeapSize = 4294967296 (4096.0MB)

NewSize = 357892096 (341.3125MB)

MaxNewSize = 1431633920 (1365.3125MB)

OldSize = 715849728 (682.6875MB)

NewRatio = 2

SurvivorRatio = 8

MetaspaceSize = 21807104 (20.796875MB)

CompressedClassSpaceSize = 1073741824 (1024.0MB)

MaxMetaspaceSize = 17592186044415 MB

G1HeapRegionSize = 0 (0.0MB)

Heap Usage:

New Generation (Eden + 1 Survivor Space):

capacity = 322109440 (307.1875MB)

used = 242418024 (231.1878433227539MB)

free = 79691416 (75.9996566772461MB)

75.2595217327378% used

Eden Space:

capacity = 286326784 (273.0625MB)

used = 241387328 (230.20489501953125MB)

free = 44939456 (42.85760498046875MB)

84.30483681191348% used

From Space:

capacity = 35782656 (34.125MB)

used = 1030696 (0.9829483032226562MB)

free = 34751960 (33.142051696777344MB)

2.88043458819826% used

To Space:

capacity = 35782656 (34.125MB)

used = 0 (0.0MB)

free = 35782656 (34.125MB)

0.0% used

tenured generation:

capacity = 715849728 (682.6875MB)

used = 12705280 (12.11669921875MB)

free = 703144448 (670.57080078125MB)

1.774852947908084% used

7067 interned Strings occupying 596016 bytes.

jmap -histo 12011，查看堆內存(histogram)中的對象數量及大小(下面 demo 內容太多，所以選取其中一部分)

jmap -histo:live 12011，查看堆內存(histogram)中的對象數量及大小，但是JVM會先觸發gc，然后再統計信息

jmap -dump:format=b,file=/opt/myHeapDumpFileName 12011，將內存使用的詳細情況輸出到文件，之后一般使用其他工具進行分析。

生成的文件可以用一些可視化工具(Eclipse Memory Analyzer 、IBM HeapAnalyzer)來查看

編號個數字節類名

508: 6 192 java.lang.invoke.LambdaForm$BasicType

509: 8 192 java.lang.invoke.MethodHandleImpl$Intrinsic

510: 8 192 java.math.RoundingMode

511: 6 192 java.net.NetworkInterface$1checkedAddresses

512: 6 192 java.rmi.server.UID

513: 3 192 java.text.DateFormatSymbols

514: 8 192 java.util.Formatter$FixedString

515: 6 192 java.util.TreeMap$KeyIterator

516: 8 192 java.util.regex.Pattern$Slice

517: 8 192 jdk.net.SocketFlow$Status

518: 6 192 net.sf.ehcache.DefaultElementEvictionData

519: 3 192 net.sf.ehcache.store.chm.SelectableConcurrentHashMap

520: 8 192 org.apache.logging.log4j.Level

521: 8 192 org.apache.logging.log4j.core.appender.rolling.RolloverFrequency

522: 4 192 org.apache.logging.log4j.core.impl.ThrowableProxy

523: 3 192 org.apache.logging.log4j.core.layout.PatternLayout

524: 12 192 org.apache.logging.log4j.core.util.datetime.FastDateParser$NumberStrategy

525: 3 192 org.apache.logging.log4j.core.util.datetime.FixedDateFormat

526: 8 192 org.apache.logging.log4j.spi.StandardLevel

527: 2 192 sun.nio.ch.ServerSocketChannelImpl

528: 4 192 sun.nio.cs.StreamEncoder

529: 6 192 sun.reflect.generics.reflectiveObjects.TypeVariableImpl

530: 11 176 java.text.NumberFormat$Field

531: 11 176 java.util.concurrent.ConcurrentSkipListSet

532: 2 176 javax.management.remote.rmi.NoCallStackClassLoader

533: 11 176 org.apache.logging.log4j.core.lookup.MapLookup

534: 8 168 [Ljava.lang.reflect.TypeVariable;

535: 1 168 [[Ljava.math.BigInteger;

jstack(線程快照 -- CPU 負載高)

jstack命令主要用來查看Java線程的調用堆棧的，可以用來分析線程問題(如死鎖)

jstack用于生成java虛擬機當前時刻的線程快照(thread dump)。主要記錄JVM在某一時刻各個線程執行的情況，以棧的形式顯示，是一個文本文件。

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

線程出現停頓的時候通過jstack來查看各個線程的調用堆棧，就可以知道沒有響應的線程到底在后臺做什么事情，或者等待什么資源。

如果java程序崩潰生成core文件，jstack工具可以用來獲得core文件的java stack和native stack的信息，從而可以輕松地知道java程序是如何崩潰和在程序何處發生問題。

另外，jstack工具還可以附屬到正在運行的java程序中，看到當時運行的java程序的java stack和native stack的信息, 如果現在運行的java程序呈現hung的狀態，jstack是非常有用的。

jstack 12011，查看線程情況

jstack -l 12011，除堆棧外，顯示關于鎖的附件信息

導出文件：jstack -l PID >> /opt/jstack-tomcat1-20180917.log

把占用 CPU 資源高的線程十進制的 PID 轉換成 16 進制：printf "%x\n" PID，比如：printf "%x\n" 12401 得到結果是：3071

在剛剛輸出的那個 log 文件中搜索：3071，可以找到：nid=0x3071

在線看某個線程 PID 的情況：jstack 進程ID | grep 十六進制線程ID -A 10

-A 10 參數用來指定顯示行數，否則只會顯示一行信息

下面 demo 內容太多，所以選取其中一部分結構：

常見線程狀態

Runnable：正在運行的線程

Sleeping：休眠的線程

Waiting：等待的線程

2018-03-08 14:28:13

Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.151-b12 mixed mode):

"Attach Listener" #53 daemon prio=9 os_prio=0 tid=0x00007f8a34009000 nid=0x865 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"Log4j2-AsyncLoggerConfig-1" #16 daemon prio=5 os_prio=0 tid=0x00007f8a5c48d800 nid=0x2f0c waiting on condition [0x00007f8a4cbfe000]

java.lang.Thread.State: WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for <0x00000007155e4850> (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 com.lmax.disruptor.BlockingWaitStrategy.waitFor(BlockingWaitStrategy.java:45)

at com.lmax.disruptor.ProcessingSequenceBarrier.waitFor(ProcessingSequenceBarrier.java:56)

at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:124)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

"Wrapper-Control-Event-Monitor" #13 daemon prio=5 os_prio=0 tid=0x00007f8a5c34e000 nid=0x2efc waiting on condition [0x00007f8a60314000]

java.lang.Thread.State: TIMED_WAITING (sleeping)

at java.lang.Thread.sleep(Native Method)

at org.tanukisoftware.wrapper.WrapperManager$3.run(WrapperManager.java:731)

"RMI TCP Accept-0" #11 daemon prio=5 os_prio=0 tid=0x00007f8a5c32f800 nid=0x2efa runnable [0x00007f8a60619000]

java.lang.Thread.State: RUNNABLE

at java.net.PlainSocketImpl.socketAccept(Native Method)

at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)

at java.net.ServerSocket.implAccept(ServerSocket.java:545)

at java.net.ServerSocket.accept(ServerSocket.java:513)

at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)

at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:400)

at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:372)

at java.lang.Thread.run(Thread.java:748)

"Service Thread" #7 daemon prio=9 os_prio=0 tid=0x00007f8a5c0b4800 nid=0x2ef3 runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"C1 CompilerThread1" #6 daemon prio=9 os_prio=0 tid=0x00007f8a5c0b1800 nid=0x2ef2 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 tid=0x00007f8a5c0af800 nid=0x2ef1 waiting on condition [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 tid=0x00007f8a5c0aa800 nid=0x2ef0 runnable [0x0000000000000000]

java.lang.Thread.State: RUNNABLE

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x00007f8a5c07b000 nid=0x2eef in Object.wait() [0x00007f8a614f4000]

java.lang.Thread.State: WAITING (on object monitor)

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

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

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

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

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

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

"VM Thread" os_prio=0 tid=0x00007f8a5c06e800 nid=0x2eed runnable

"VM Periodic Task Thread" os_prio=0 tid=0x00007f8a5c332000 nid=0x2efb waiting on condition

JNI global references: 281

資料

總結

以上是生活随笔為你收集整理的linux at java,Linux-Tutorial/Java-bin.md at master · linsanityHuang/Linux-Tutorial · GitHub的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： linux http 分析工具,技术|h
下一篇： linux mint 用户管理,Linu