多核可扩展计数器
到處都需要計(jì)數(shù)器，例如，查找應(yīng)用程序的關(guān)鍵KPI，應(yīng)用程序的負(fù)載，服務(wù)的請求總數(shù)，用于查找應(yīng)用程序吞吐量的一些KPI等。
由于所有這些需求，并發(fā)復(fù)雜性也增加了，這使這個問題變得有趣。
如何實(shí)現(xiàn)并發(fā)計(jì)數(shù)器
- 同步 –這是JDK 1.5之前的唯一選項(xiàng)，因?yàn)楝F(xiàn)在我們正在等待JDK8版本，因此絕對不是一個選項(xiàng)。
- 基于鎖 –切勿嘗試將其用作計(jì)數(shù)器，否則它將性能很差
- 等待免費(fèi) -Java不支持Fetch-and-add ，因此實(shí)現(xiàn)起來有點(diǎn)困難。
- 無鎖 –很好地支持“ 比較和交換” ，使用起來不錯。
基于比較和交換的計(jì)數(shù)器如何執(zhí)行
我使用AtomicInteger進(jìn)行此測試，并且每個線程使此計(jì)數(shù)器遞增1百萬次，以增加線程的爭用數(shù)量，并逐漸增加。
試驗(yàn)機(jī)詳細(xì)信息
作業(yè)系統(tǒng)：Windows 8
JDK：1.7.0.25
處理器：Intel i7-3632QM，8 Core
內(nèi)存：8 GB
Y軸 –增加一百萬次所需的時間
X軸–螺紋數(shù)
隨著線程數(shù)量的增加，增加計(jì)數(shù)器所花費(fèi)的時間也增加了，這是由于爭用造成的。 對于基于CAS的計(jì)數(shù)器，是CAS故障導(dǎo)致減速。
這是我們可以獲得的最佳性能嗎？ 肯定不是它們是實(shí)現(xiàn)并發(fā)計(jì)數(shù)器的更好的解決方案，讓我們來看看它們。
備用并發(fā)計(jì)數(shù)器
讓我們看一些實(shí)現(xiàn)計(jì)數(shù)器的解決方案，以更好的方式處理競爭：
- 基于核心的計(jì)數(shù)器 –維護(hù)每個邏輯核心的計(jì)數(shù)器，這樣您的爭用就會減少。 您擁有這種類型的計(jì)數(shù)器的唯一問題是，如果線程數(shù)大于邏輯核心數(shù)，那么您將開始注意到競爭。
- 基于線程的計(jì)數(shù)器 –維護(hù)將使用系統(tǒng)的線程總數(shù)的計(jì)數(shù)器。 當(dāng)線程數(shù)大于邏輯核心數(shù)時，這很好地工作。
讓我們測試一下
不同類型的計(jì)數(shù)器花費(fèi)的時間
Y軸 –增加一百萬次所需的時間
X軸–螺紋數(shù)
同時用計(jì)數(shù)器進(jìn)行比基于原子計(jì)數(shù)器要好得多，16個線程是5倍左右的時間比較好，這是巨大的差異！
CAS失效率
Y軸 – CAS失效100Ks
X軸–螺紋數(shù)
由于爭用，基于原子的計(jì)數(shù)器會出現(xiàn)很多故障，并且隨著我添加更多線程和其他計(jì)數(shù)器的性能提高，它會呈指數(shù)增長。
觀察
多核計(jì)算機(jī)變得易于使用，并且我們必須改變處理并發(fā)的方式，傳統(tǒng)的并發(fā)方式在當(dāng)今時代無法擴(kuò)展，因?yàn)閾碛?4或48核服務(wù)器非常普遍。
- 為了減少爭用，您必須使用多個計(jì)數(shù)器，然后再將它們聚合
- 如果線程數(shù)少于或等于內(nèi)核數(shù)，則基于內(nèi)核的計(jì)數(shù)器效果很好
- 當(dāng)線程數(shù)量遠(yuǎn)大于可用內(nèi)核時，基于線程的計(jì)數(shù)器就很好
- 減少爭用的關(guān)鍵是確定要寫入哪個線程的計(jì)數(shù)器。我使用了基于線程ID的簡單方法，但是可以使用更好的方法，請查看JDK 8的ThreadLocalRandom以獲得一些想法。
- JDK8的LongAdder使用基于線程的方法，該方法創(chuàng)建許多插槽以減少爭用。
Github提供了此測試中使用的所有計(jì)數(shù)器的代碼
翻譯自: https://www.javacodegeeks.com/2013/09/scalable-counters-for-multi-core.html
總結(jié)
- 上一篇： Google GSON入门
- 下一篇： 基本注射/资格赛，范围