欧美日韩国产一区二区三区不卡 ,日韩人妻毛片中文字幕

UnixFileSystem中需要對一個新文件的路徑按照操作系統(tǒng)標(biāo)準(zhǔn)進(jìn)行標(biāo)準(zhǔn)化。
標(biāo)準(zhǔn)化的結(jié)果存放在ExpiringCache對象中。

多個線程都在爭相調(diào)用ExpiringCache#put操作，這側(cè)面反映了文件列表的高頻變化，這說明系統(tǒng)中存在高頻的Flush和Merge操作。
這加劇了我關(guān)于使用姿勢的懷疑：”細(xì)雨綿綿”式的寫入，被動觸發(fā)Flush，如果周期相同，意味著同時Flush，多個Shard同時Merge的概率變大。
于是，我開始在測試環(huán)境中模擬這種使用方式，創(chuàng)建類似的分片數(shù)量，控制寫入頻率。計(jì)劃讓測試程序至少運(yùn)行一天的時間，觀察是否可以復(fù)現(xiàn)此問題。在程序運(yùn)行的同時，我繼續(xù)調(diào)查Thread Dump日志。
第3點(diǎn)現(xiàn)象中，僅僅是做一次hash計(jì)算，卻表現(xiàn)出特別慢的樣子。如果將這三點(diǎn)現(xiàn)象綜合起來，可以發(fā)現(xiàn)所有的調(diào)用點(diǎn)都在做CPU計(jì)算。按理說，CPU應(yīng)該特別的忙碌。
等問題在現(xiàn)場復(fù)現(xiàn)的時候，客戶協(xié)助獲取了CPU使用率與負(fù)載信息，結(jié)果顯示CPU資源非常閑。在這之前，同事也調(diào)研過IO資源，也是非常閑的。這排除了系統(tǒng)資源方面的影響。此時也發(fā)現(xiàn)，每一次復(fù)現(xiàn)的節(jié)點(diǎn)是隨機(jī)的，與機(jī)器無關(guān) 。
一天過去后，在本地測試環(huán)境中，問題沒能復(fù)現(xiàn)出來。盡管使用姿勢不優(yōu)雅，但卻不像是問題的癥結(jié)所在。
03 詭異的STW中斷
通過jstack命令獲取Thread Dump日志時，需要讓JVM進(jìn)程進(jìn)入Safepoint，相當(dāng)于整個進(jìn)程先被掛起。獲取到的Thread Dump日志，也恰恰是進(jìn)程掛起時每個線程的瞬間狀態(tài) 。
所有忙碌的線程都剛好在做CPU計(jì)算，但CPU并不忙碌。這提示需要進(jìn)一步調(diào)查GC日志。
現(xiàn)場應(yīng)用并未開啟GC日志 ?？紤]到問題當(dāng)前尚未復(fù)現(xiàn)，通過jstat工具來查看GC次數(shù)與GC統(tǒng)計(jì)時間的意義不太大。讓現(xiàn)場人員在jvm.options中手動添加了如下參數(shù)來開啟GC日志：

 8:-XX:+PrintGCDetails
8:-XX:+PrintGCDateStamps
8:-XX:+PrintTenuringDistribution
8:-XX:+PrintGCApplicationStoppedTime
8:-Xloggc:logs/gc.log
8:-XX:+UseGCLogFileRotation
8:-XX:NumberOfGCLogFiles=32
8:-XX:GCLogFileSize=32m

添加
PrintGCApplicationStoppedTime是為了將每一次JVM進(jìn)程發(fā)生的STW(Stop-The-World)中斷記錄在GC日志中。通常，此類STW中斷都是因GC引起，也可能與偏向鎖有關(guān) 。
剛剛重啟，現(xiàn)場人員把GC日志tail的結(jié)果發(fā)了過來，這是為了確認(rèn)配置已生效。詭異的是，剛剛重啟的進(jìn)程居然在不停的打印STW日志：

關(guān)于STW日志(”…Total time for which application threads were stopped…”)，這里有必要簡單解釋一下：
JVM有時需要執(zhí)行一些全局操作，典型如GC、偏向鎖回收，此時需要暫停所有正在運(yùn)行的Thread，這需要依賴于JVM的Safepoint機(jī)制，Safepoint就好比一條大馬路上設(shè)置的紅燈。JVM每一次進(jìn)入STW（Stop-The-World）階段，都會打印這樣的一行日志：

2020-09-10T13:59:43.210+0800: 73032.559: Total time for which application threads were stopped: 0.0002853 seconds, Stopping threads took: 0.0000217 seconds

在這行日志中，提示了STW階段持續(xù)的時間為0.0002853秒，而叫停所有的線程(Stopping threads)花費(fèi)了0.0000217秒，前者包含了后者。通常，Stopping threads的時間占比極小，如果過長的話可能與代碼實(shí)現(xiàn)細(xì)節(jié)有關(guān)，這里不過多展開。
回到問題，一開始就打印大量的STW日志，容易想到與偏向鎖回收有關(guān) 。直到問題再次復(fù)現(xiàn)時，拿到了3個節(jié)點(diǎn)的完整的GC日志，發(fā)現(xiàn)無論是YGC還是FGC，觸發(fā)的頻次都很低，這排除了GC方面的影響。
出現(xiàn)的大量STW日志，使我意識到該現(xiàn)象極不合理。有同學(xué)提出懷疑，每一次中斷時間很短?。繉懥艘粋€簡單的工具，對每一分鐘的STW中斷頻次、中斷總時間做了統(tǒng)計(jì)：