JVM(5) JVM 引數詳解
晚上忽然發現自己的MAC從執行程式到看到Spring boot日誌時間超過20秒。新建個空的boot空工程也需要10秒才會看到boot的啟動日誌。
最後設定了gc日誌看了下有無異常情況。
從jvisualvm看下
Java HotSpot(TM) 64-Bit Server VM (25.131-b11) for bsd-amd64 JRE (1.8.0_131-b11), built on Mar 15 2017 01:32:22 by "java_re" with gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11 .00)
Memory: 4k page, physical 16777216k(1562132k free)
/proc/meminfo:
CommandLine flags: -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC
2017 -08-10T23:55:58.799-0800: 0.989: [GC (Allocation Failure) [PSYoungGen: 65536K->10005K(76288K)] 65536K->10085K(251392K), 0.0103069 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
下面舉個JVM引數配置的例子
-verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/Users/bao/data/read_mes/gclogs/boot_gc .log
java -Dcom.zhht.server.http.port=8088 -jar -verbose:gc -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/data/aipark_gc.log aipark-1.0.0.jar
檢視GC日誌
Java HotSpot(TM) 64-Bit Server VM (24.79-b02) for linux-amd64 JRE (1.7.0_79-b15), built on Apr 10 2015 11:34:48 by "java_re" with gcc 4.3.0 20080428 (Red Hat 4.3.0-8)
Memory: 4k page, physical 3974056k(3205108k free), swap 2097148k(2097148k free)
CommandLine flags: -XX:InitialHeapSize=63584896 -XX:MaxHeapSize=1017358336 -XX:+PrintGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedOops -XX:+UseParallelGC
2017-09-20T22:39:41.840-0400: 1.118: [GC [PSYoungGen: 15872K->2486K(18432K)] 15872K->2494K(59904K), 0.0086080 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
2017-09-20T22:39:42.289-0400: 1.566: [GC [PSYoungGen: 18358K->2528K(18432K)] 18366K->2624K(59904K), 0.0224750 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
2017-09-20T22:39:42.718-0400: 1.995: [GC [PSYoungGen: 18400K->2544K(18432K)] 18496K->4152K(59904K), 0.0107510 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
2017-09-20T22:39:43.240-0400: 2.518: [GC [PSYoungGen: 18416K->2544K(34304K)] 20024K->7621K(75776K), 0.0186720 secs] [Times: user=0.03 sys=0.00, real=0.02 secs]
2017-09-20T22:39:44.108-0400: 3.386: [GC [PSYoungGen: 34288K->2528K(34304K)] 39372K->11032K(75776K), 0.0190170 secs] [Times: user=0.03 sys=0.01, real=0.02 secs]
相關推薦
JVM(5) JVM 引數詳解
晚上忽然發現自己的MAC從執行程式到看到Spring boot日誌時間超過20秒。新建個空的boot空工程也需要10秒才會看到boot的啟動日誌。 最後設定了gc日誌看了下有無異常情況。 從jv
JVM配置引數詳解
一、堆引數設定 -XX:+PrintGC 使用這個引數,虛擬機器啟動後,只要遇到GC就會列印日誌 -XX:+UseSerialGC 配置序列回收器 -XX:+PrintGCDetails 可以檢視詳細資訊,包括各個區的情況 -Xms:設定Java程式啟動
JVM堆記憶體管理與自定義分配引數詳解
堆記憶體模型: 在Java中,堆被劃分成兩個不同的區域:新生代(Young),老年代(Old)。而Permanent屬於永久代(方法區),不屬於堆記憶體。新生代又被分為了三個區域:Eden,from survivor,to survivor。這樣劃分的目的
JVM引數詳解垃圾回收調優
一、常用JVM配置引數1.1基本引數 -client,-server 這兩個引數用於設定虛擬機器使用何種執行模式,client模式啟動比較快,但執行時效能 和記憶體 管理效率不如server模式,通常用於客戶端應用程式。相反,server
JVM效能調優的6大步驟,及關鍵調優引數詳解
JVM效能調優的6大步驟,及關鍵調優引數詳解 JVM效能調優方法和步驟 1.監控GC的狀態 2.生成堆的dump檔案 3.分析dump檔案 4.分析結果,判斷是否需要優化 5.調整GC型別和記憶體分配 6.不斷分析
JVM -verbose引數詳解(轉)
java -verbose[:class|gc|jni] 在輸出裝置上顯示虛擬機器執行資訊。 1.java -verbose:class 在程式執行的時候有多少類被載入!你可以用verbose:class來監視,在命令列輸入java -verbose:class XXX
JVM記憶體引數詳解以及配置調優
基本概念: PermGen space:全稱是Permanent Generation space。就是說是永久儲存的區域,用於存放Class和Meta資訊,Class在被Load的時候被放入該區域 Heap space:存放Instance。GC(Garbage Collection)應該不會對PermGe
JVM 引數詳解
-XX 引數被稱為不穩定引數,之所以這麼叫是因為此類引數的設定很容易引起JVM 效能上的差異,使JVM 存在極大的不穩定性。當然這是在非合理設定的前提下,如果此類引數設定合理講大大提高JVM 的效能及穩定性。 可以說“不穩定引數”是一柄雙刃劍,用的好攻無不克,用
JVM 啟動引數詳解
JAVA虛擬機器(JVM)通過作業系統命令JAVA_HOME\bin\java –option 來啟動,-option為虛擬機器引數,JAVA_HOME為JDK安裝路徑,通過這些引數可對虛擬機器的執行狀態進行調整,掌握引數的含義可對虛擬機器的執行模式有更深入的理解。虛擬機器
JVM內存模型詳解
基本 過程 nio 認識 靜態變量 maxperm 工作原理 函數 不變 JVM內存模型也叫JVM運行時區域,是認識和了解JVM工作原理的基礎,從java誕生以來,JVM內存模型基本保持著大同小異的整體形態,由此可見JVM內存模型是相當穩定的,直到jdk1.8之後JVM內存
JVM的GC理論詳解
階段 eee throw 應該 pub WAD cte 操作 內存減半 目錄 GC的概念 回收算法 引用計數算法:(老牌垃圾回收算法。無法處理循環引用,沒有被Java采納) 1、引用計數算法的概念: 根搜索算法 標記-清除算法 復制算法:(新生代的GC) 標記-整理
JVM的GC實現詳解
垃圾收集器 預留空間 最短 compact jvm .com 碎片整理 www. 如果 目錄 收集器: 串行收集器:Serial收集器 並行收集器 CMS收集器 新生代中的98%對象都是“朝生夕死”的,所以並不需要按照1:1的比例來劃分內存空間,而是將內
JVM系列(二) - JVM內存區域詳解
type system oot 用途 block 引入 locals -o 以及 前言 JVM內存區域包括 PC計數器、Java虛擬機棧、本地方法棧、堆、方法區、運行時常量池和 直接內存。 本文主要介紹各個內存區域的作用和特性,同時分別闡述各個區域發生內存溢出的可能性和異
JVM 虛擬機器棧詳解
棧幀 棧幀 (Stack Frame) 是用於支援虛擬機器進行方法呼叫和方法執行的資料結構,它是虛擬機器執行時資料區中的虛擬機器棧 (Virtual Machine Stack)的棧元素 。棧幀儲存了方法的區域性變量表、運算元棧、動態連線和方法返回地址等資訊。每一個方能從
jvm整體架構圖文詳解
今天學習了jvm三大組成部分(jvm類載入器,jvm記憶體結構,jvm執行引擎)的記憶體結構,現在把學習筆記總結記錄一下,當作複習吧。 1.jvm的概念 JVM(虛擬機器):指以軟體的方式模擬具有完整硬體系統功能、執行在一個完全隔離環境中的完整計算機系統 ,是物理機的軟體實現。 jvm和
JVM 類載入機制詳解
原文出處: ziwenxie 如下圖所示,JVM類載入機制分為五個部分:載入,驗證,準備,解析,初始化,下面我們就分別來看一下這五個過程。 載入 載入是類載入過程中的一個階段,這個階段會在記憶體中生成一個代表這個類的java.lang.Class物件,作為方法區這個類的
jvm垃圾收集機制詳解(下)
上一篇傳送門:jvm垃圾收集機制詳解(中) 三、HotSpot虛擬機器的垃圾收集實現 根據之前的講解,java分析物件是否需要被回收是通過對物件的可達性分析來確定的,而可達性分析是通過識別物件是否連結到GC Roots物件決定的。那麼很顯然,我們需要通過遍歷所有的GC Roots節點
jvm垃圾收集機制詳解(中)
上一篇傳送門:jvm垃圾收集機制詳解(上) 二、垃圾收集演算法(僅演算法思想) 1.標記清除演算法 標記清除演算法是另外兩種垃圾回收演算法的基礎,之所以說是基礎是因為這種演算法僅僅是簡簡單單地把標記了需要清除的物件進行了回收而已,除此之外沒有任何其它操作。這種演算法有很多不足,例
jvm垃圾收集機制詳解(上)
在我們學習java之前,經常聽到的一個關於java的優點就是,相對於像C語言這種語言,省去了程式設計師手動回收垃圾的步驟,那麼,java虛擬機器到底是怎麼實現自動垃圾回收機制的呢? 一、如何判斷物件需要被回收 什麼時候需要回收物件?經常寫別的語言的人可能會說,當我們對一個東西使用完成
jvm垃圾回收演算法詳解
在JDK1.8+的版本中,JVM記憶體管理結構有了一定的優化調整。主要是方法區(持久代)取消變成了直接使用元資料區(直接記憶體)的方式,但是整體上JVM的結構並沒有大改,特別是我們最為關心的堆記憶體管理方式並沒有在JDK1.8+的版本中有什麼變化,所以圖中的結構