無法加載可擴展計數器

到處都需要計數器，例如，查找應用程序的關鍵KPI，應用程序的負載，服務的請求總數，用于查找應用程序吞吐量的一些KPI等。

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

如何實現并發計數器

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

基于比較和交換的計數器如何執行

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

試驗機詳細信息

作業系統：Windows 8

JDK：1.7.0.25

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

內存：8 GB

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

X軸–螺紋數

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

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

備用并發計數器

讓我們看一些實現計數器的解決方案，以更好的方式處理競爭：

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

讓我們測試一下

不同類型的計數器花費的時間

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

X軸–螺紋數

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

CAS失效率

Y軸 – CAS失效100Ks

X軸–螺紋數

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

觀察

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

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

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

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

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

無法加載可擴展計數器

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。