在研究ByteWatcher時(shí) （請參閱我的上一篇 文章 ），我遇到了一些非常奇怪的事情。

這是實(shí)際的代碼段，用于找出特定線程上的分配量：

return (long) mBeanServer.invoke(name,GET_THREAD_ALLOCATED_BYTES,PARAMS,SIGNATURE );

• 有關(guān)完整上下文，請參見此處 。

（ByteWatcher的工作方式是定期調(diào)用此方法以監(jiān)視分配。）

需要注意的一個(gè)重要方面，尤其是當(dāng)想要為程序的分配提供準(zhǔn)確的數(shù)字時(shí)，就是調(diào)用上面的代碼本身–導(dǎo)致分配。

此調(diào)用引起的分配必須從返回的數(shù)中扣除，以便我們隔離程序?qū)е碌姆峙?#xff0c;即， 調(diào)用meanBeanServer =程序線程分配+調(diào)用開銷

我注意到的是，此分配量通常為336個(gè)字節(jié)。 但是，當(dāng)我在循環(huán)中調(diào)用此方法時(shí)，發(fā)現(xiàn)了一些有趣的東西。 每隔一段時(shí)間，它將分配不同的金額。

對于此測試：

@Testpublic void testQuietMeasuringThreadAllocatedBytes() {ByteWatcherSingleThread am = new ByteWatcherSingleThread();System.out.println("MeasuringCostInBytes = " + am.getMeasuringCostInBytes());long[] marks = new long[1_000_000];for (int i = 0; i < 1_000_000; i++) {marks[i] = am.threadAllocatedBytes();}long prevDiff = -1;for (int i = 1; i < 1_000_000; i++) {long diff = marks[i] - marks[i - 1];if (prevDiff != diff)System.out.println("Allocation changed at iteration " + i + "->" + diff);prevDiff = diff;}}

這是典型的結(jié)果：

MeasuringCostInBytes = 336 Allocation changed at iteration 1->336 Allocation changed at iteration 12->28184 Allocation changed at iteration 13->360 Allocation changed at iteration 14->336 Allocation changed at iteration 1686->600 Allocation changed at iteration 1687->336 Allocation changed at iteration 2765->672 Allocation changed at iteration 2766->336 Allocation changed at iteration 5458->496 Allocation changed at iteration 5459->336 Allocation changed at iteration 6213->656 Allocation changed at iteration 6214->336 Allocation changed at iteration 6535->432 Allocation changed at iteration 6536->336 Allocation changed at iteration 6557->8536 Allocation changed at iteration 6558->336 Allocation changed at iteration 7628->576 Allocation changed at iteration 7629->336 Allocation changed at iteration 8656->4432 Allocation changed at iteration 8657->336 Allocation changed at iteration 9698->968 Allocation changed at iteration 9699->336 Allocation changed at iteration 11881->1592 Allocation changed at iteration 11882->336 Allocation changed at iteration 12796->1552 Allocation changed at iteration 12797->336 Allocation changed at iteration 13382->456 Allocation changed at iteration 13383->336 Allocation changed at iteration 14844->608 Allocation changed at iteration 14845->336 Allocation changed at iteration 36685->304 Allocation changed at iteration 52522->336 Allocation changed at iteration 101440->400 Allocation changed at iteration 101441->336

鑒于程序中肯定沒有分配，所以為什么同一調(diào)用有時(shí)分配不同的金額對我來說是一個(gè)謎。

總的來說，超過1,000,000次運(yùn)行，該程序分配了大約25次不同的數(shù)量。 值得注意的是，經(jīng)過10萬次迭代后沒有峰值。

我與亨氏·卡布茲（Heinz Kabutz）和克里斯·紐蘭（Chris Newland）分享了這個(gè)問題。 Chris注意到分配是由JIT編譯抖動引起的。 通過使用標(biāo)志-Xint重新運(yùn)行測試可以很清楚地看出這一點(diǎn)（僅以解釋模式運(yùn)行，即沒有JIT編譯）。 現(xiàn)在只有2個(gè)峰值。

MeasuringCostInBytes = 336 Allocation changed at iteration 1->336 Allocation changed at iteration 12->28184 Allocation changed at iteration 13->360 Allocation changed at iteration 14->336

同樣使用-Xcomp標(biāo)志運(yùn)行（僅編譯）：

MeasuringCostInBytes = 336 Allocation changed at iteration 1->336 Allocation changed at iteration 12->29696 Allocation changed at iteration 13->360 Allocation changed at iteration 14->336

因此，現(xiàn)在我們可以非常有信心，正是導(dǎo)致準(zhǔn)入分配的JIT編譯抖動。

我不完全理解為什么會這樣，但是我想這是可以理解的。 為了彌補(bǔ)這一點(diǎn)，我在ByteWatcher的構(gòu)造函數(shù)中引入了一個(gè)校準(zhǔn)階段，Heinz進(jìn)一步完善了該校準(zhǔn)階段。

您可以在此處看到校準(zhǔn)代碼，但是它包含兩個(gè)階段：

調(diào)用該方法以計(jì)算線程在緊密循環(huán)中分配了多少（我們稱其為100,000次）–允許JIT適當(dāng)?shù)仡A(yù)熱代碼，以便將其全部編譯

等待50毫秒–這使JVM有機(jī)會完成編譯抖動

在構(gòu)造函數(shù)中使用此代碼，即使沒有特殊標(biāo)志運(yùn)行也不會出現(xiàn)分配高峰。

結(jié)論

• JIT編譯抖動導(dǎo)致一些分配
• 在沒有編譯抖動（即僅解釋或僅編譯）的情況下運(yùn)行程序會大大減少分配，但并不能完全消除分配。
• 在100k運(yùn)行之后，分配停止，這表明需要100k運(yùn)行才能停止抖動。 這很有趣，因?yàn)槲覀冎来a應(yīng)該在10k次迭代后進(jìn)行編譯。

翻譯自: https://www.javacodegeeks.com/2015/09/an-unexpected-allocation-jit-compilation-jitter.html

總結(jié)

以上是生活随笔為你收集整理的意外分配– JIT编译抖动的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。