日韩小视频在线,精品视频一区二区三区,牛牛av

JVM常用命令行參數

1. 查看參數列表

虛擬機參數分為基本和擴展兩類，在命令行中輸入 JAVA_HOME\bin\java就可得到基本參數列表。
在命令行輸入 JAVA_HOME\bin\java –X就可得到擴展參數列表。

2. 基本參數說明：

-client，-server： 兩種Java虛擬機啟動方式，client模式啟動比較快，但是性能和內存管理相對較差，server模式啟動比較慢，但是運行性能比較高，windos上采用的是client模式，Linux采用server模式
-classpath -cp： 虛擬機在運行一個類的時候，需要將其轉入內存中，虛擬機搜索類的方式和順序：Bootstrap classes、Extension classes、User classes。
Bootstrap 中的路徑是虛擬機自帶的 jar 或 zip 文件，虛擬機首先搜索這些包文件，用System.getProperty(“sun.boot.class.path”)可得到虛擬機搜索的包名。
Extension 是位于 jre\lib\ext 目錄下的 jar 文件，虛擬機在搜索完 Bootstrap 后就搜索該目錄下的 jar 文件。用 System. getProperty("java.ext.dirs”)可得到虛擬機使用
Extension 搜索路徑。
User classes 搜索順序為當前目錄、環境變量 CLASSPATH、-classpath。
-classpath： 告訴虛擬機搜索目錄名、jar文檔名、zip文檔名
-verbose[:class|gc|jni]： 在輸出設備上顯示虛擬機運行信息
-verbose:class 輸出虛擬機裝入的類的信息
-verbose:gc 在虛擬機發生內存回收時輸出設備信息，用來監視虛擬機內存回收的情況
-verbose:jni 虛擬機調用native方法時輸出設置顯示信息，用來監視虛擬機調用本地方法的情況
-version：顯示可運行的虛擬機版本信息
-showversion：顯示版本信息以及幫助信息

3. 擴展參數說明：

-Xmixed： 設置 -client 模式虛擬機對使用頻率高的方式進行 Just-In-Time 編譯和執行，對其他方法使用解釋方式執行，該方式是虛擬機缺省模式
-Xint： 設置-client模式下運行的虛擬機以解釋方式執行類的字節碼，不將字節碼編譯為本機碼，有可能會損失性能
-Xbootclasspath:path、-Xbootclasspath/a:path、-Xbootclasspath/p:path： 改變虛擬機裝載系統運行包 rt.jar，而從-Xbootclasspath 中設定的搜索路徑中裝載系統運行類。除非你自己能寫一個運行時，否則不會用到該參數。
/a:將在缺省搜索路徑后加上 path 中的搜索路徑。
/p:在缺省搜索路徑前先搜索 path 中的搜索路徑。
-Xnoclassgc： 關閉虛擬機對 class 的垃圾回收功能，有可能會導致OutOfMemoryError
-Xincgc： 啟動增量垃圾收集器，缺省是關閉的，增量垃圾收集器能減少偶然發生的長時間的垃圾回收造成的暫停時間，但增量垃圾收集器和應用程序并發執行，會占用部分CPU在應用程序上的功能
-Xloggc:file： 將虛擬機每次垃圾回收的信息寫到日志文件中，文件名由file指定，文件格式是平文件，內容和-verbose:gc 輸出內容相同
-Xms20M： 設置虛擬機可用內存堆的初始大小為20M，大小為1024的整數倍并且要大于1MB，可用K或者M為單位來設置較大內存數，初始堆大小為2MB，例如：-Xms256M
-Xmx20M： 設置虛擬機內存堆的最大可用大小，該值必須為1024的整數倍，并且要大于2MB，可用K或者M為單位來設置較大的內存數，例如：-Xmx81920K，-Xmx80M，當應用程序申請了大內存運行時虛擬機拋出 java.lang.OutOfMemoryError，就需要使用-Xmx來設置了
-Xss128K： 設置線程棧的大小，和-Xmx類似，可以用K或M來設置較大的值，也可以在Java中創建線程對象時設置棧的大小
-Xoss128k： 設置本地方法棧的大小為128K，不過HotSpot不區分虛擬機棧和本地方法棧，所以這個參數對于HotSpot是無效的
-XX:PermSize=10M： 表示JVM初始分配的永久代的容量，必須以M為單位
-XX:MaxPermSize=10M： 表示JVM允許分配的永久代的最大容量，必須以M為單位，大部分情況下這個參數默認為64M
-XX:NewRatio=4： 表示設置年輕代：老年代的大小比值為1：4，這意味著年輕代占整個堆的1/5
-XX:SurvivorRatio=8： 表示設置2個Survivor區：1個Eden區的大小比值為2:8，這意味著Survivor區占整個年輕代的1/5，這個參數默認為8
-Xmn20M： 表示設置年輕代的大小為20M
-XX:+HeapDumpOnOutOfMemoryError： 表示可以讓虛擬機在出現內存溢出異常時Dump出當前的堆內存轉儲快照
-XX:+UseG1GC： 表示讓JVM使用G1垃圾收集器
-XX:+PrintGCDetails： 表示在控制臺上打印出GC具體細節
-XX:+PrintGC： 表示在控制臺上打印出GC信息
-XX:PretenureSizeThreshold=3145728 表示對象大于3145728（3M）時直接進入老年代分配，這里只能以字節作為單位
-XX:MaxTenuringThreshold=1： 表示對象年齡大于1，自動進入老年代

虛擬機參數分類

標準： - 開頭，所有的HotSpot都支持
非標準：-X 開頭，特定版本HotSpot支持特定命令
不穩定：-XX 開頭，下個版本可能取消

例如：java -version、java -X

				?

									import java.util.List;

									import java.util.LinkedList;

									public class HelloGC {

									  public static void main(String[] args) {

									    System.out.println("HelloGC!");

									    List list = new LinkedList();

									    for(;;) {

									      byte[] b = new byte[1024*1024];

									      list.add(b);

									    }

									  }

									}

java虛擬機之JVM調優詳解

區分概念：內存泄漏memory leak，內存溢出out of memory
java -XX:+PrintCommandLineFlags HelloGC
java -Xmn10M -Xms40M -Xmx60M -XX:+PrintCommandLineFlags -XX:+PrintGC HelloGC
PrintGCDetails PrintGCTimeStamps PrintGCCauses
java -XX:+UseConcMarkSweepGC -XX:+PrintCommandLineFlags HelloGC
java -XX:+PrintFlagsInitial 默認參數值
java -XX:+PrintFlagsFinal 最終參數值
java -XX:+PrintFlagsFinal | grep xxx 找到對應的參數
java -XX:+PrintFlagsFinal -version |grep GC

調優前的基礎概念

1. 吞吐量：用戶代碼時間 /（用戶代碼執行時間 + 垃圾回收時間）
2. 響應時間： STW（Stop The World）越短，響應時間越好

所謂的調優，首先自己要明確，想要的是什么，是吞吐量還是響應時間，還是在滿足一定的響應時間的情況下，要求達到多大的吞吐量，一般來說根據業務類型去選擇對應的調優方式，比如網站需要的是響應時間優先，JDK1.8盡量選G1，那如果是數據挖掘的需要使用的是吞吐量。

什么是調優

在沒有接觸過調優之前我們理解的JVM調優就是解決OOM問題，OOM只是JVM調優的一部分

一般是根據需求進行JVM規劃和預調優優化運行JVM運行環境（慢，卡頓）解決JVM運行過程中出現的各種問題(OOM)

首先的話，調優是從業務場景開始的，如果沒有業務場景的JVM調優都是不靠譜的，比如有時間在實際項目中，有很多個類，成千上萬個代碼，你怎么知道具體是哪個代碼有問題，就算我們知道有段代碼頻繁的full gc，但是可能過一段時間就OOM了。

1.調優步驟：

熟悉業務場景，選定垃圾回收器（沒有最好的垃圾回收器，只有最合適的垃圾回收器）
響應時間、停頓時間 [CMS G1 ZGC] （需要給用戶作響應）吞吐量 = 用戶時間 /( 用戶時間 + GC時間) [PS]
選擇回收器組合
計算內存需求（設置內存大小 1.5G 16G）
選定CPU：越高越好
設定年代大小、升級年齡
設定日志參數

-Xloggc:/opt/xxx/logs/xxx-xxx-gc-%t.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCCause或者每天產生一個日志文件

在生產環境中日志文件，后面日志名字，按照系統時間產生，循環產生，日志個數五個，每個大小20M，這樣的好處在于整體大小100M，能控制整體文件大小

觀察日志情況

2.調優案例

2.1案例一

垂直電商，最高每日百萬訂單，處理訂單系統需要什么樣的服務器配置

這個問題比較雞肋，因為很多不同的服務器配置都能夠支撐

比如有一百萬個訂單，每個小時不會產生很高的并發量，我們尋找高峰時間，做一個假設100W訂單有72W訂單在高峰期產生，比如一個小時平均36W訂單，所以我們內存選擇大小是按照巔峰時間選擇的，很多時間我們可能就是去做壓測，實在不行就添加CPU和內存

2.2案例二

12306遭遇春節大規模搶票應該如何支撐

訂單信息每天固定，可以丟到緩存中，不同的業務邏輯有不同的業務設計，12306應該是中國并發量最大的秒殺網站，號稱并發100W，就是說每秒進行百萬次的業務邏輯的處理，估計淘寶一年最高的是54W并發。

如果解決這個問題呢，看下面所示：

CDN -》 LVS -》 NGINX -》業務系統 -》每臺機器1W并發

普通電商的下單流程一般是：

訂單 -》下單-》訂單系統減庫存 -》等待用戶付款

這個事務如果同步的方式完成，TPS是支撐不了多長時間的

但是在12306里面的模型是

下單-》減庫存和訂單同時異步進行 -》等待付款

異步是當你下完訂單之后，它一個線程去減庫存，另外一個線程直接把你下單的信息扔到kafka或者redis里面直接返回OK，你下單成功后等待你付款，什么時候你付款完成后面那些個訂單處理線程就會去里面拿數據，這個處理完了就會持久化到Hbase或者是mysql，一般大流量的處理方法核心思想就是：分而治之

JVM優化

比如我有一個50萬PV的資料類網站（從磁盤提取文檔到內存）原服務器32位，1.5G的堆，用戶反饋網站比較緩慢，如果對它進行升級，新服務器64位，16G的堆內存，用戶還是反饋卡頓，而且還比之前更嚴重，這個是因為什么呢？一般來說很多用戶去瀏覽數據，很多數據會load到內存中，導致內存不足，頻繁的GC，STW時間過長，響應時間就會變慢，那我們應該怎么辦呢，使用 PS-> PN+CMS或者G1。

還有一個就是系統CPU經常100%,我們要如何進行調優呢？

首先我們可以想到CPU100%那么一定有線程在占用系統資源

1.找出哪個進程CPU高（top命令）

2.該進程中的哪個線程CPU高（top -Hp）

3.導出該線程的堆棧

4.查找哪個方法（棧掙）比較消耗時間

5.工作線程占比高 | 垃圾回收線程占比高