seata之jvm参数解析
微信公眾號：我其實目前沒有耶
我是一個互聯(lián)網(wǎng)公司的螺絲釘;
魔術(shù)師耿
JVM啟動參數(shù)解析
疑問1 :生產(chǎn)環(huán)境上常用哪些JVM參數(shù)進(jìn)行設(shè)置;
疑問2 :sh 啟動jar 包并配置JVM參數(shù)樣例怎么寫;
疑問3 :dockerfile 怎么配置(seata 源碼的 distribution中有他們的Dockerfile配置)
疑問4 :怎樣在IDEA中搜索 jdk中的源碼中的關(guān)鍵字
今天以seata服務(wù)的啟動腳本seata-server.sh為例,進(jìn)行分析 疑問1和疑問2
exec "$JAVACMD" $JAVA_OPTS -server -Xmx2048m -Xms2048m -Xmn1024m -Xss512k -XX:SurvivorRatio=10 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=1024m -XX:-OmitStackTraceInFastThrow -XX:-UseAdaptiveSizePolicy -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath="$BASEDIR"/logs/java_heapdump.hprof -XX:+DisableExplicitGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -Xloggc:"$BASEDIR"/logs/seata_gc.log -verbose:gc -Dio.netty.leakDetectionLevel=advanced \-classpath "$CLASSPATH" \-Dapp.name="seata-server" \-Dapp.pid="$$" \-Dapp.repo="$REPO" \-Dapp.home="$BASEDIR" \-Dbasedir="$BASEDIR" \io.seata.server.Server \"$@"其中
- exec “$JAVACMD” $JAVA_OPTS -server -Xmx2048m -Xms2048m -Xmn1024m -Xss512k
-server 第一個參數(shù)
-Xmx2048m heap最大值
-Xms2048m 堆初始值
-Xmn1024m 不是堆最小值,而是新生代的大小(Sun官方推薦配置為整個堆的3/8)
-Xss512k Stack Space棧空間的大小 設(shè)置每個線程的堆棧大小。JDK5.0以后每個線程堆棧大小為1MB，以前每個線程堆棧大小為256K。
-XX:SurvivorRatio=10 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:MaxDirectMemorySize=1024m
-XX:SurvivorRatio=10 新生代分為Eden ，兩塊Survivor；計算Survivor大小， Eden:Survivor = 10，總大小為1024,10x+x+x=1024 x=85
-
-XX:-OmitStackTraceInFastThrow
1、jvm啟動參數(shù)中沒有配置-XX:-OmitStackTraceInFastThrow，
參數(shù)：OmitStackTraceInFastThrow字面意思是省略異常棧信息從而快速拋出。
會引起error日志顯示不全的問題
該文章貼上了JDK那一段源碼: https://blog.csdn.net/diaoliwei2/article/details/959662662、OmitStackTraceInFastThrow和StackTraceInThrowable都默認(rèn)為true。
如果想關(guān)閉這個優(yōu)化，配置-XX:-OmitStackTraceInFastThrow，StackTraceInThrowable保持默認(rèn)配置-XX:+OmitStackTraceInFastThrow即可。JVM只對幾個特定類型異常開啟了Fast Throw優(yōu)化，這些異常包括: : NullPointerException
所以條件 (!StackTraceInThrowable || OmitStackTraceInFastThrow)為true，即JVM默認(rèn)開啟了Fast Throw優(yōu)化。- ArithmeticException
ArrayIndexOutOfBoundsException
ArrayStoreException
ClassCastException3、下面寫個循環(huán)調(diào)用空指針異常測試一下：在循環(huán)了2800多次后，還是能正常打出堆棧信息。再之后就簡化了異常輸出。
4、修改JVM 啟動參數(shù)，添加OmitStackTraceInFastThrow后。循環(huán)7000次異常信息還是正常輸出。
- ArithmeticException
-
-XX:-UseAdaptiveSizePolicy
https://www.jianshu.com/p/7414fd6862c5
AdaptiveSizePolicy(自適應(yīng)大小策略) 是 JVM GC Ergonomics(自適應(yīng)調(diào)節(jié)策略) 的一部分。
如果開啟 AdaptiveSizePolicy，則每次 GC 后會重新計算 Eden、From 和 To 區(qū)的大小，
計算依據(jù)是 GC 過程中統(tǒng)計的 GC 時間、吞吐量、內(nèi)存占用量。
JDK 1.8 默認(rèn)使用 UseParallelGC 垃圾回收器，該垃圾回收器默認(rèn)啟動了 AdaptiveSizePolicy。
由 AdaptiveSizePolicy 引發(fā)的 GC 問題
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath="$BASEDIR"/logs/java_heapdump.hprof
-
-XX:+DisableExplicitGC ##禁止代碼中顯示調(diào)用GC
java nio中的direct memory，那么使用-XX:+DisableExplicitGC一定要小心，存在潛在的內(nèi)存泄露風(fēng)險
最佳編程實踐是：暴露出釋放資源的接口，程序員使用完成后，顯示釋放，這樣就能夠避免堆內(nèi)存和非堆內(nèi)存資源的同步釋放的難題。
RevisedObjectInHeap類中通過finalize()方法來釋放堆外內(nèi)存的，閱讀源碼可以發(fā)現(xiàn)，NIO中direct memory的釋放并不是通過finalize()，
而是通過sun.misc.Cleaner實現(xiàn)的
cleaner = Cleaner.create(this, new Deallocator(base, cap));
為什么不用finalize呢？因為finalize不安全，也非常影響性能。什么是sun.misc.Cleaner？這是個幽靈引用PhantomReference
-XX:+CMSParallelRemarkEnabled ## 并行標(biāo)記
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=75 ##設(shè)定CMS在對內(nèi)存占用率達(dá)到75%的時候開始GC
-Xloggc:"$BASEDIR"/logs/seata_gc.log ##
-verbose:gc
-Dio.netty.leakDetectionLevel=advanced
這句話報告有泄漏的發(fā)生，提示你用-D參數(shù)，把防漏等級從默認(rèn)的simple升到advanced， 具體看到被泄漏的ByteBuf創(chuàng)建的地方和被訪問的地方。https://www.iteye.com/news/30866Netty里四種主力的ByteBuf， 其中UnpooledHeapByteBuf 底下的byte[]能夠依賴JVM GC自然回收； 而UnpooledDirectByteBuf底下是DirectByteBuffer，如Java堆外內(nèi)存掃盲貼所述，除了等JVM GC， 最好也能主動進(jìn)行回收；而PooledHeapByteBuf 和 PooledDirectByteBuf，則必須要主動將用完的byte[]/ByteBuffer放回池里， 否則內(nèi)存就要爆掉。所以，Netty ByteBuf需要在JVM的GC機(jī)制之外，有自己的引用計數(shù)器和回收過程。一下又回到了C的冰冷時代，自己malloc對象要自己free。 但和C時代又不完全一樣，內(nèi)有引用計數(shù)器，外有JVM的GC，情況更為復(fù)雜。2. 引用計數(shù)器常識 計數(shù)器基于 AtomicIntegerFieldUpdater，為什么不直接用AtomicInteger？因為ByteBuf對象很多，如果都把int包一層AtomicInteger花銷較大，而AtomicIntegerFieldUpdater只需要一個全局的靜態(tài)變量。 所有ByteBuf的引用計數(shù)器初始值為1。 調(diào)用release()，將計數(shù)器減1，等于零時， deallocate()被調(diào)用，各種回收。 調(diào)用retain()，將計數(shù)器加1，即使ByteBuf在別的地方被人release()了，在本Class沒喊cut之前，不要把它釋放掉。 由duplicate(), slice()和order(ByteOrder)所創(chuàng)建的ByteBuf，與原對象共享底下的buffer，也共享引用計數(shù)器，所以它們經(jīng)常需要調(diào)用retain()來顯示自己的存在。 當(dāng)引用計數(shù)器為0，底下的buffer已被回收，即使ByteBuf對象還在，對它的各種訪問操作都會拋出異常。3.誰來負(fù)責(zé)Release在C時代，我們喜歡讓malloc和free成對出現(xiàn)，而在Netty里，因為Handler鏈的存在，ByteBuf經(jīng)常要傳遞到下一個Hanlder去而不復(fù)還，所以規(guī)則變成了誰是最后使用者，誰負(fù)責(zé)釋放。另外，更要注意的是各種異常情況，ByteBuf沒有成功傳遞到下一個Hanlder，還在自己地界里的話，一定要進(jìn)行釋放。3.1 InBound Message 在AbstractNioByteChannel.NioByteUnsafe.read() 處，配置好的ByteBufAllocator創(chuàng)建相應(yīng)ByteBuf并調(diào)用 pipeline.fireChannelRead(byteBuf) 送入Handler鏈。根據(jù)上面的誰最后誰負(fù)責(zé)原則，每一個Handler對消息可能有三種處理方式對原消息不做處理，調(diào)用 ctx.fireChannelRead(msg)把原消息往下傳，那不用做什么釋放。 將原消息轉(zhuǎn)化為新的消息并調(diào)用 ctx.fireChannelRead(newMsg)往下傳，那必須把原消息release掉。 如果已經(jīng)不再調(diào)用ctx.fireChannelRead(msg)傳遞任何消息，那更要把原消息release掉。 假設(shè)每一個Handler都把消息往下傳，Handler并也不知道誰是啟動Netty時所設(shè)定的Handler鏈的最后一員，所以Netty會在Handler鏈的最末補(bǔ)一個TailHandler，如果此時消息仍然是ReferenceCounted類型就會被release掉。 不過如果我們的業(yè)務(wù)Hanlder不再把消息往下傳了，這個TailHandler就派不上用場。 3.2 OutBound Message 要發(fā)送的消息通常由應(yīng)用所創(chuàng)建，并調(diào)用 ctx.writeAndFlush(msg) 進(jìn)入Handler鏈。在每一個Handler中的處理類似InBound Message，最后消息會來到HeadHandler，再經(jīng)過一輪復(fù)雜的調(diào)用，在flush完成后終將被release掉。3.3 異常發(fā)生時的釋放 多層的異常處理機(jī)制，有些異常處理的地方不一定準(zhǔn)確知道ByteBuf之前釋放了沒有，可以在釋放前加上引用計數(shù)大于0的判斷避免異常；有時候不清楚ByteBuf被引用了多少次，但又必須在此進(jìn)行徹底的釋放，可以循環(huán)調(diào)用reelase()直到返回true。4. 內(nèi)存泄漏檢測所謂內(nèi)存泄漏，主要是針對池化的ByteBuf。ByteBuf對象被JVM GC掉之前，沒有調(diào)用release()去把底下的DirectByteBuffer或byte[]歸還到池里，會導(dǎo)致池越來越大。而非池化的ByteBuf，即使像DirectByteBuf那樣可能會用到System.gc()，但終歸會被release掉的，不會出大事。Netty擔(dān)心大家一定會不小心就搞出個大新聞來，因此提供了內(nèi)存泄漏的監(jiān)測機(jī)制。Netty默認(rèn)就會從分配的ByteBuf里抽樣出大約1%的來進(jìn)行跟蹤。如果泄漏，會有如下語句打印： 引用LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call ResourceLeakDetector.setLevel()這句話報告有泄漏的發(fā)生，提示你用-D參數(shù)，把防漏等級從默認(rèn)的simple升到advanced，具體看到被泄漏的ByteBuf創(chuàng)建的地方和被訪問的地方。 禁用（DISABLED） - 完全禁止泄露檢測，省點消耗。 簡單（SIMPLE） - 默認(rèn)等級，告訴我們?nèi)拥?%的ByteBuf是否發(fā)生了泄露，但總共一次只打印一次，看不到就沒有了。 高級（ADVANCED） - 告訴我們?nèi)拥?%的ByteBuf發(fā)生泄露的地方。每種類型的泄漏（創(chuàng)建的地方與訪問路徑一致）只打印一次。 偏執(zhí)（PARANOID） - 跟高級選項類似，但此選項檢測所有ByteBuf，而不僅僅是取樣的那1%。在高壓力測試時，對性能有明顯影響。實現(xiàn)細(xì)節(jié) 每當(dāng)各種ByteBufAllocator 創(chuàng)建ByteBuf時，都會問問是否需要采樣，Simple和Advanced級別下，就是以113這個素數(shù)來取模（害我看文檔的時候還在瞎擔(dān)心，1％，萬一泄漏的地方有所規(guī)律，剛好躲過了100這個數(shù)字呢，比如都是3倍數(shù)的），命中了就創(chuàng)建一個Java堆外內(nèi)存掃盲貼里說的PhantomReference。然后創(chuàng)建一個Wrapper，包住ByteBuf和Reference。Simple級別下，wrapper只在執(zhí)行release()時調(diào)用Reference.clear()把Reference清理掉，Advanced級別下則會記錄每一個創(chuàng)建和訪問的動作。當(dāng)GC發(fā)生，還沒有被clear()的Reference就會被JVM放入到之前設(shè)定的ReferenceQueue里。在每次創(chuàng)建PhantomReference時，都會順便看看有沒有因為忘記執(zhí)行release()把Reference給clear掉，在GC時被放進(jìn)了ReferenceQueue的對象，有則以 "io.netty.util.ResourceLeakDetector”為logger name，寫出前面例子里的Error級別的日日志。順便說一句，Netty能自動匹配日志框架，先找Slf4j，再找Log4j，最后找JDK logger
-classpath “KaTeX parse error: Undefined control sequence: \ at position 12: CLASSPATH" \? ? -Dapp.name="s…KaTeX parse error: Undefined control sequence: \ at position 3: " \? ? -Dapp.repo="REPO”
-Dapp.home=“KaTeX parse error: Undefined control sequence: \ at position 10: BASEDIR" \? ? -Dbasedir="BASEDIR”
io.seata.server.Server
“$@”
怎么優(yōu)化tomcat的jvm參數(shù)
#修改JVM參數(shù)不直接修改 catalina.bat 和catalina.sh
在catalina.sh同級目錄創(chuàng)建setenv.sh文件
在里面修改jvm參數(shù)
參看 https://www.iteye.com/blog/tdcq-1990666
#!/bin/sh # ================================================================== echo "start set env" echo "$CATALINA_BASE"export CATALINA_OPTS="$CATALINA_OPTS -Xmx6144m -Xms4096m -Xmn2048m -Xss512k -XX:SurvivorRatio=10 -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:-OmitStackTraceInFastThrow -XX:-UseAdaptiveSizePolicy -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=$CATALINA_BASE/logs/ir_heapdump.hprof -XX:+DisableExplicitGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -Xloggc:$CATALINA_BASE/logs/ir_gc.log -verbose:gc "以seata 的dockerfile 為例 分析疑問3
以檢索 case Deoptimization::Reason_null_check: 為例
直接ctrl + h 搜索不到
請教博文作者DreamTHT , 說是在 這個文件里 https://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/opto/graphKit.cpp ,
牛掰, 我真不懂 c++
參看這篇博文https://blog.csdn.net/daerzei/article/details/79717717
-
修改 點擊菜單File --> Project Structure --> SDKs --> Sourcepath ,添加上本地源碼解壓吧路徑C:\dev\jdk\jdk_source
此時可以編輯源碼添加注釋 -
修改 點擊Setting --> Build,Execution,Deployment --> Debugger --> Stepping
把Do not step into the classes中的ajva.*，javax.*取消勾選，其他的隨意
此時可以debug對源碼打斷點
你好,大神
總結(jié):
? seata的這些參數(shù)設(shè)置還真是挺有講究的呀…不愧是大廠的專家呀!!!
接下來任務(wù)很重呀,我要把自己之前學(xué)會了,又丟掉的東西寫個博客記錄下來了。
我說我是一個入行快10年的程序員，你敢新？該死該死。
在此把我珍藏了多年的第一篇博文，獻(xiàn)給各位吧。 后續(xù)會不停更新。每周至少一篇吧。保底
我是魔術(shù)師耿，一個IT行業(yè)的搬磚人。
總結(jié)
以上是生活随笔為你收集整理的seata之jvm参数解析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
