無法加載可擴展計數(shù)器

到處都需要計數(shù)器，例如，查找應(yīng)用程序的關(guān)鍵KPI，應(yīng)用程序的負(fù)載，服務(wù)的請求總數(shù)，用于查找應(yīng)用程序吞吐量的一些KPI等。

由于所有這些需求，并發(fā)復(fù)雜性也增加了，這使這個問題變得有趣。

如何實現(xiàn)并發(fā)計數(shù)器

• 同步 –這是JDK 1.5之前的唯一選項，因為現(xiàn)在我們正在等待JDK8發(fā)布，因此絕對不是一個選項。
• 基于鎖 –切勿嘗試將其用作計數(shù)器，否則它將性能很差
• 等待免費 -Java不支持Fetch-and-add ，因此實現(xiàn)起來有點困難。
• 無鎖 –在“ 比較和交換”的良好支持下，此選項看起來不錯。

基于比較和交換的計數(shù)器如何執(zhí)行

我使用AtomicInteger進行此測試，并且每個線程使此計數(shù)器遞增1百萬次，以增加線程的爭用數(shù)量，并逐漸增加。

試驗機詳細(xì)信息

作業(yè)系統(tǒng)：Windows 8

JDK：1.7.0.25

處理器：Intel i7-3632QM，8 Core

內(nèi)存：8 GB

Y軸 –增加一百萬次所需的時間

X軸–螺紋數(shù)

隨著線程數(shù)量的增加，增加計數(shù)器所花費的時間也增加了，這是由于爭用造成的。 對于基于CAS的計數(shù)器，是CAS故障導(dǎo)致減速。

這是我們可以獲得的最佳性能嗎？ 肯定不是它們是實現(xiàn)并發(fā)計數(shù)器的更好的解決方案，讓我們來看看它們。

備用并發(fā)計數(shù)器

讓我們看一些實現(xiàn)計數(shù)器的解決方案，以更好的方式處理競爭：

• 基于核心的計數(shù)器 –維護每個邏輯核心的計數(shù)器，這樣您將減少爭用。 您擁有這種類型的計數(shù)器的唯一問題是，如果線程數(shù)大于邏輯核心數(shù)，那么您將開始注意到競爭。
• 基于線程的計數(shù)器 –維護計數(shù)器以了解將要使用系統(tǒng)的線程總數(shù)。 當(dāng)線程數(shù)大于邏輯核心數(shù)時，此方法效果很好。

讓我們測試一下

不同類型的計數(shù)器花費的時間

Y軸 –增加一百萬次所需的時間

X軸–螺紋數(shù)

同時用計數(shù)器進行比基于原子計數(shù)器要好得多，16個線程是5倍左右的時間比較好，這是巨大的差異！

CAS失效率

Y軸 – CAS失效100Ks

X軸–螺紋數(shù)

由于存在爭用，基于原子的計數(shù)器會出現(xiàn)很多故障，并且隨著我添加更多線程和其他計數(shù)器的運行而呈指數(shù)級增長。

觀察

多核計算機變得易于使用，并且我們必須改變處理并發(fā)的方式，而當(dāng)擁有24或48核服務(wù)器的情況很普遍時，傳統(tǒng)的并發(fā)方式在當(dāng)今時代將無法擴展。

• 為了減少爭用，您必須使用多個計數(shù)器，然后再將它們聚合
• 如果線程數(shù)少于或等于內(nèi)核數(shù)，則基于內(nèi)核的計數(shù)器效果很好
• 當(dāng)線程數(shù)量遠大于可用內(nèi)核時，基于線程的計數(shù)器就很好
• 減少爭用的關(guān)鍵是確定要寫入哪個線程的計數(shù)器。我使用了基于線程ID的簡單方法，但是可以使用更好的方法，請查看JDK 8的ThreadLocalRandom以獲得一些想法。
• JDK8的LongAdder使用基于線程的方法，該方法創(chuàng)建許多插槽以減少爭用。

該測試中使用的所有計數(shù)器的代碼都可以在Github上獲得

參考：來自JCG合作伙伴 Ashkrit Sharma的“ 多核可擴展計數(shù)器 ”，準(zhǔn)備好博客了。

翻譯自: https://www.javacodegeeks.com/2013/09/scalable-counters-for-multi-core.html

無法加載可擴展計數(shù)器

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的无法加载可扩展计数器_多核可扩展计数器的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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