追加字節能優化性能

• 這種方式看起來很神奇，單若是深刻理解處理器架構就能理解其中的奧祕。讓咱們先來看看LinkedTransferQueue這個類，它使用一個內部類型來定義隊列的頭隊列Head和尾節點tail，二這個內部類PaddedAtomicReference相對於父類AtomicReference只作了一件事情，就將共享變量共佔60個字節，再加上父類的Value變量，一共64個字節。爲何追加64字節可以提升併發編程的效率呢？由於對於因特爾酷睿i7，酷睿，Atom和NetBurst，Core Sole和Pentium M處理器的L1，L2和L3緩存的高速緩存行是64個字節寬，不支持部分填充緩存行，這意味着若是隊列的頭節點和尾節點都不足64字節的話，處理器會將他們都讀到同一個高速緩存行中，在多處理器下每一個處理器都會緩存一樣的頭尾節點，當一個處理器試圖修改頭接點時會將整個緩存行鎖定，那麼在在緩存一致性機制的做用下，會致使其餘處理器不能訪問本身高速緩存中的尾節點，而隊列的出隊和出隊操做時須要不停修改頭接點和尾節點，因此在多處理器的狀況下將會嚴重影響到隊列的入隊和出隊效率。Doug lea使用追加到64字節的方式來填滿高速緩存區的緩存行，避免頭節點和尾節點加載到同一個緩存行，使得頭尾節點在修改時不會互相鎖定。
• 那麼是否是在使用Volatile變量時都應該追加到64字節呢？不是的，在兩種情景下不該該使用這種方式。第一：緩存行非64字節寬的處理器，他們的L1和L2的高速緩存行是32個字節寬。第二：共享變量不會被頻繁的寫。所以使用追加字節的方式須要處理器讀取更多的字節到高速緩存區，這本省就會帶來必定的性能損耗，共享變量若是不被頻繁寫的話，鎖的概率也很是的小，就不必經過追加字節的方式來避免相互鎖定。