每个程序员都应该了解的 CPU 高速缓存 - 开源中国社区
每个程序员都应该了解的 CPU 高速缓存
英文原文：
Editor's note: This is the second installment in Ulrich Drepper's &What every programmer should know about memory& document. Those who have not read
will likely want to start there. This is good stuff, and we once again thank Ulrich for allowing us to publish it.
One quick request: in a document of this length there are bound to be a few typographical errors remaining. If you find one, and wish to see it corrected, please let us know via mail to
rather than by posting a comment. That way we will be sure to incorporate the fix and get it back into Ulrich's copy of the document and other readers will not have to plow through uninteresting comments.]
[编者按：这是Ulrich Drepper写“程序员都该知道存储器”的第二部。那些没有读过 的读者可能希望从这一部开始。这本书写的非常好，并且感谢Ulrich授权我们出版。
一点说明：书籍出版时可能会有一些印刷错误，如果你发现，并且想让它在后续的出版中更正，请将意见发邮件到 ，我们一定会更正，并反馈给Ulrich的文档副本，别的读者就不会受到这些困扰。]
CPUs are today much more sophisticated than they were only 25 years ago. In those days, the frequency of the CPU core was at a level equivalent to that of the memory bus. Memory access was only a bit slower than register access. But this changed dramatically in the early 90s, when CPU designers increased the frequency of the CPU core but the frequency of the memory bus and the performance of RAM chips did not increase proportionally. This is not due to the fact that faster RAM could not be built, as explained in the previous section. It is possible but it is not economical. RAM as fast as current CPU cores is orders of magnitude more expensive than any dynamic RAM.
现在的CPU比25年前要精密得多了。在那个年代，CPU的频率与内存总线的频率基本在同一层面上。内存的访问速度仅比寄存器慢那么一点点。但是，这一局面在上世纪90年代被打破了。CPU的频率大大提升，但内存总线的频率与内存芯片的性能却没有得到成比例的提升。并不是因为造不出更快的内存，只是因为太贵了。内存如果要达到目前CPU那样的速度，那么它的造价恐怕要贵上好几个数量级。
If the choice is between a machine with very little, very fast RAM and a machine with a lot of relatively fast RAM, the second will always win given a working set size which exceeds the small RAM size and the cost of accessing secondary storage media such as hard drives. The problem here is the speed of secondary storage, usually hard disks, which must be used to hold the swapped out part of the working set. Accessing those disks is orders of magnitude slower than even DRAM access.
Fortunately it does not have to be an all-or-nothing decision. A computer can have a small amount of high-speed SRAM in addition to the large amount of DRAM. One possible implementation would be to dedicate a certain area of the address space of the processor as containing the SRAM and the rest the DRAM. The task of the operating system would then be to optimally distribute data to make use of the SRAM. Basically, the SRAM serves in this situation as an extension of the register set of the processor.
如果有两个选项让你选择，一个是速度非常快、但容量很小的内存，一个是速度还算快、但容量很多的内存，如果你的工作集比较大，超过了前一种情况，那么人们总是会选择第二个选项。原因在于辅存(一般为磁盘)的速度。由于工作集超过主存，那么必须用辅存来保存交换出去的那部分数据，而辅存的速度往往要比主存慢上好几个数量级。
好在这问题也并不全然是非甲即乙的选择。在配置大量DRAM的同时，我们还可以配置少量SRAM。将地址空间的某个部分划给SRAM，剩下的部分划给DRAM。一般来说，SRAM可以当作扩展的寄存器来使用。
While this is a possible implementation, it is not viable. Ignoring the problem of mapping the physical resources of such SRAM-backed memory to the virtual address spaces of the processes (which by itself is terribly hard) this approach would require each process to administer in software the allocation of this memory region. The size of the memory region can vary from processor to processor (i.e., processors have different amounts of the expensive SRAM-backed memory). Each module which makes up part of a program will claim its share of the fast memory, which introduces additional costs through synchronization requirements. In short, the gains of having fast memory would be eaten up completely by the overhead of administering the resources.
上面的做法看起来似乎可以，但实际上并不可行。首先，将SRAM内存映射到进程的虚拟地址空间就是个非常复杂的工作，而且，在这种做法中，每个进程都需要管理这个SRAM区内存的分配。每个进程可能有大小完全不同的SRAM区，而组成程序的每个模块也需要索取属于自身的SRAM，更引入了额外的同步需求。简而言之，快速内存带来的好处完全被额外的管理开销给抵消了。
So, instead of putting the SRAM under the control of the OS or user, it becomes a resource which is transparently used and administered by the processors. In this mode, SRAM is used to make temporary copies of (to cache, in other words) data in main memory which is likely to be used soon by the processor. This is possible because program code and data has temporal and spatial locality. This means that, over short periods of time, there is a good chance that the same code or data gets reused. For code this means that there are most likely loops in the code so that the same code gets executed over and over again (the perfect case for spatial locality). Data accesses are also ideally limited to small regions. Even if the memory used over short time periods is not close together there is a high chance that the same data will be reused before long (temporal locality). For code this means, for instance, that in a loop a function call is made and that function is located elsewhere in the address space. The function may be distant in memory, but calls to that function will be close in time. For data it means that the total amount of memory used at one time (the working set size) is ideally limited but the memory used, as a result of the random access nature of RAM, is not close together. Realizing that locality exists is key to the concept of CPU caches as we use them today.
其它翻译版本：1(点击译者名切换)
因此，SRAM是作为CPU自动使用和管理的一个资源，而不是由OS或者用户管理的。在这种模式下，SRAM用来复制保存（或者叫缓存）主内存中有可能即将被CPU使用的数据。这意味着，在较短时间内，CPU很有可能重复运行某一段代码，或者重复使用某部分数据。从代码上看，这意味着CPU执行了一个循环，所以相同的代码一次又一次地执行（空间局部性的绝佳例子）。数据访问也相对局限在一个小的区间内。即使程序使用的物理内存不是相连的，在短期内程序仍然很有可能使用同样的数据（时间局部性）。这个在代码上表现为，程序在一个循环体内调用了入口一个位于另外的物理地址的函数。这个函数可能与当前指令的物理位置相距甚远，但是调用的时间差不大。在数据上表现为，程序使用的内存是有限的（相当于工作集的大小）。但是实际上由于RAM的随机访问特性，程序使用的物理内存并不是连续的。正是由于空间局部性和时间局部性的存在，我们才提炼出今天的CPU缓存概念。
A simple computation can show how effective caches can theoretically be. Assume access to main memory takes 200&cycles and access to the cache memory take 15&cycles. Then code using 100 data elements 100 times each will spend 2,000,000&cycles on memory operations if there is no cache and only 168,500&cycles if all data can be cached. That is an improvement of 91.5%.
The size of the SRAM used for caches is many times smaller than the main memory. In the author's experience with workstations with CPU caches the cache size has always been around 1/1000th of the size of the main memory (today: 4MB cache and 4GB main memory). This alone does not constitute a problem. If the size of the working set (the set of data currently worked on) is smaller than the cache size it does not matter. But computers do not have large main memories for no reason. The working set is bound to be larger than the cache. This is especially true for systems running multiple processes where the size of the working set is the sum of the sizes of all the individual processes and the kernel.
我们先用一个简单的计算来展示一下高速缓存的效率。假设，访问主存需要200个周期，而访问高速缓存需要15个周期。如果使用100个数据元素100次，那么在没有高速缓存的情况下，需要2000000个周期，而在有高速缓存、而且所有数据都已被缓存的情况下，只需要168500个周期。节约了91.5%的时间。
用作高速缓存的SRAM容量比主存小得多。以我的经验来说，高速缓存的大小一般是主存的千分之一左右(目前一般是4GB主存、4MB缓存)。这一点本身并不是什么问题。只是，计算机一般都会有比较大的主存，因此工作集的大小总是会大于缓存。特别是那些运行多进程的系统，它的工作集大小是所有进程加上内核的总和。
What is needed to deal with the limited size of the cache is a set of good strategies to determine what should be cached at any given time. Since not all data of the working set is used at exactly the same time we can use techniques to temporarily replace some data in the cache with other data. And maybe this can be done before the data is actually needed. This prefetching would remove some of the costs of accessing main memory since it happens asynchronously with respect to the execution of the program. All these techniques and more can be used to make the cache appear bigger than it actually is. We will discuss them in Section 3.3. Once all these techniques are exploited it is up to the programmer to help the processor. How this can be done will be discussed in Section 6.
处理高速缓存大小的限制需要制定一套很好的策略来决定在给定的时间内什么数据应该被缓存。由于不是所有数据的工作集都是在完全相同的时间段内被使用的，我们可以用一些技术手段将需要用到的数据临时替换那些当前并未使用的缓存数据。这种预取将会减少部分访问主存的成本，因为它与程序的执行是异步的。所有的这些技术将会使高速缓存在使用的时候看起来比实际更大。我们将在3.3节讨论这些问题。
我们将在第6章讨论如何让这些技术能很好地帮助程序员，让处理器更高效地工作。
3.1 CPU Caches in the Big Picture
Before diving into technical details of the implementation of CPU caches some readers might find it useful to first see in some more details how caches fit into the “big picture” of a modern computer system.
Figure 3.1: Minimum Cache Configuration
Figure 3.1 shows the minimum cache configuration. It corresponds to the architecture which could be found in early systems which deployed CPU caches. The CPU core is no longer directly connected to the main memory. {In even earlier systems the cache was attached to the system bus just like the CPU and the main memory. This was more a hack than a real solution.} All loads and stores have to go through the cache. The connection between the CPU core and the cache is a special, fast connection. In a simplified representation, the main memory and the cache are connected to the system bus which can also be used for communication with other components of the system. We introduced the system bus as “FSB” which is t see Section 2.2. In this section we ignore the N it is assumed to be present to facilitate the communication of the CPU(s) with the main memory.
3.1 高速缓存的位置
在深入介绍高速缓存的技术细节之前，有必要说明一下它在现代计算机系统中所处的位置。
图3.1: 最简单的高速缓存配置图
图3.1展示了最简单的高速缓存配置。早期的一些系统就是类似的架构。在这种架构中，CPU核心不再直连到主存。{在一些更早的系统中，高速缓存像CPU与主存一样连到系统总线上。那种做法更像是一种hack，而不是真正的解决方案。}数据的读取和存储都经过高速缓存。CPU核心与高速缓存之间是一条特殊的快速通道。在简化的表示法中，主存与高速缓存都连到系统总线上，这条总线同时还用于与其它组件通信。我们管这条总线叫“FSB”——就是现在称呼它的术语，参见第2.2节。在这一节里，我们将忽略北桥。
Even though computers for the last several decades have used the von Neumann architecture, experience has shown that it is of advantage to separate the caches used for code and for data. Intel has used separate code and data caches since 1993 and never looked back. The memory regions needed for code and data are pretty much independent of each other, which is why independent caches work better. In recent years another advantage emerged: the instruction decoding step for the most commo caching decoded instructions can speed up the execution, especially when the pipeline is empty due to incorrectly predicted or impossible-to-predict branches.
在过去的几十年，经验表明使用了冯诺伊曼结构的
计算机，将用于代码和数据的高速缓存分开是存在巨大优势的。自1993年以来，Intel
并且一直坚持使用独立的代码和数据高速缓存。由于所需的代码和数据的内存区域是几乎相互独立的，这就是为什么独立缓存工作得更完美的原因。近年来，独立缓存的另一个优势慢慢显现出来：常见处理器解码
指令的步骤
是缓慢的，尤其当管线为空的时候，往往会伴随着错误的预测或无法预测的分支的出现，
将高速缓存技术用于
解码可以加快其执行速度。
Soon after the introduction of the cache, the system got more complicated. The speed difference between the cache and the main memory increased again, to a point that another level of cache was added, bigger and slower than the first-level cache. Only increasing the size of the first-level cache was not an option for economical reasons. Today, there are even machines with three levels of cache in regular use. A system with such a processor looks like Figure 3.2. With the increase on the number of cores in a single CPU the number of cache levels might increase in the future even more.
Figure 3.2: Processor with Level 3 Cache
Figure 3.2 shows three levels of cache and introduces the nomenclature we will use in the remainder of the document. L1d is the level&1 data cache, L1i the level&1 instruction cache, etc. Note that the data flow in reality need not pass through any of the higher-level caches on the way from the core to the main memory. CPU designers have a lot of freedom designing the interfaces of the caches. For programmers these design choices are invisible.
在高速缓存出现后不久，系统变得更加复杂。高速缓存与主存之间的速度差异进一步拉大，直到加入了另一级缓存。新加入的这一级缓存比第一级缓存更大，但是更慢。由于加大一级缓存的做法从经济上考虑是行不通的，所以有了二级缓存，甚至现在的有些系统拥有三级缓存，如图3.2所示。随着单个CPU中核数的增加，未来甚至可能会出现更多层级的缓存。
图3.2: 三级缓存的处理器
图3.2展示了三级缓存，并介绍了本文将使用的一些术语。L1d是一级数据缓存，L1i是一级指令缓存，等等。请注意，这只是示意图，真正的数据流并不需要流经上级缓存。CPU的设计者们在设计高速缓存的接口时拥有很大的自由。而程序员是看不到这些设计选项的。CPU，一般认为写C/C++的才需要了解，写高级语言的(Java/C#/pathon...)并不需要了解那么底层的东西。我一开始也是这么想的，但直到碰到LMAX的，以及，才发现写Java的，更加不能忽视CPU。经过一段时间的阅读，希望总结一下自己的阅读后的感悟。本文主要谈谈CPU缓存对Java编程的影响，不涉及具体CPU缓存的机制和实现。
现代CPU的缓存结构一般分三层，L1，L2和L3。如下图所示：
级别越小的缓存，越接近CPU， 意味着速度越快且容量越少。
L1是最接近CPU的，它容量最小，速度最快，每个核上都有一个L1 Cache(准确地说每个核上有两个L1 Cache， 一个存数据 L1d Cache， 一个存指令 L1i Cache)；
L2 Cache 更大一些，例如256K，速度要慢一些，一般情况下每个核上都有一个独立的L2 Cache；
L3 Cache是三级缓存中最大的一级，例如12MB，同时也是最慢的一级，在同一个CPU插槽之间的核共享一个L3 Cache。
当CPU运作时，它首先去L1寻找它所需要的数据，然后去L2，然后去L3。如果三级缓存都没找到它需要的数据，则从内存里获取数据。寻找的路径越长，耗时越长。所以如果要非常频繁的获取某些数据，保证这些数据在L1缓存里。这样速度将非常快。下表表示了CPU到各缓存和内存之间的大概速度：
从CPU到 & & 　　大约需要的CPU周期 &大约需要的时间(单位ns)寄存器 & & & &　　1 cycle L1 Cache & 　　&~3-4 cycles & & & & &~0.5-1 nsL2 Cache 　　　~10-20 cycles 　　~3-7 nsL3 Cache 　　　~40-45 cycles 　　~15 ns跨槽传输　　　　　　　　　　　　　&~20 ns内存 　　　　　 &~120-240 cycles &~60-120ns
利用CPU-Z可以查看CPU缓存的信息：
在linux下可以使用下列命令查看：
有了上面对CPU的大概了解，我们来看看缓存行(Cache line)。缓存，是由缓存行组成的。一般一行缓存行有64字节(由上图"64-byte line size"可知)。所以使用缓存时，并不是一个一个字节使用，而是一行缓存行、一行缓存行这样使用；换句话说，CPU存取缓存都是按照一行，为最小单位操作的。
这意味着，如果没有好好利用缓存行的话，程序可能会遇到性能的问题。可看下面的程序：
1 public class L1CacheMiss {
private static final int RUNS = 10;
private static final int DIMENSION_1 = 1024 * 1024;
private static final int DIMENSION_2 = 6;
private static long[][]
public static void main(String[] args) throws Exception {
Thread.sleep(10000);
longs = new long[DIMENSION_1][];
for (int i = 0; i & DIMENSION_1; i++) {
longs[i] = new long[DIMENSION_2];
for (int j = 0; j & DIMENSION_2; j++) {
longs[i][j] = 0L;
System.out.println("starting....");
long sum = 0L;
for (int r = 0; r & RUNS; r++) {
final long start = System.nanoTime();
for (int j = 0; j & DIMENSION_2; j++) {
for (int i = 0; i & DIMENSION_1; i++) {
sum += longs[i][j];
for (int i = 0; i & DIMENSION_1; i++) {
for (int j = 0; j & DIMENSION_2; j++) {
sum += longs[i][j];
System.out.println((System.nanoTime() - start));
以我所使用的Xeon E3 CPU和64位操作系统和64位JVM为例，如所说，假设编译器采用行主序存储数组。
64位系统，Java数组对象头固定占16字节（未证实），而long类型占8个字节。所以16+8*6=64字节，刚好等于一条缓存行的长度：
如32-36行代码所示，每次开始内循环时，从内存抓取的数据块实际上覆盖了longs[i][0]到longs[i][5]的全部数据（刚好64字节）。因此，内循环时所有的数据都在L1缓存可以命中，遍历将非常快。
假如，将32-36行代码注释而用25-29行代码代替，那么将会造成大量的缓存失效。因为每次从内存抓取的都是同行不同列的数据块（如longs[i][0]到longs[i][5]的全部数据），但循环下一个的目标，却是同列不同行（如longs[0][0]下一个是longs[1][0]，造成了longs[0][1]-longs[0][5]无法重复利用）。运行时间的差距如下图，单位是微秒(us)：
最后，我们都希望需要的数据都在L1缓存里，但事实上经常事与愿违，所以缓存失效 (Cache Miss)是常有的事，也是我们需要避免的事。
一般来说，缓存失效有三种情况：
1. 第一次访问数据, 在cache中根本不存在这条数据, 所以cache miss, 可以通过解决。
2. cache冲突, 需要通过补齐来解决（伪共享的产生）。
3. cache满, 一般情况下我们需要减少操作的数据大小, 尽量按数据的物理顺序访问数据。
阅读(...) 评论()Java后端为主
一篇对伪共享、缓存行填充和CPU缓存讲的很透彻的文章
看了很多网上讲解java伪共享、缓存行填充和CPU缓存的MESI等等，零零碎碎，目前感觉就这篇文章讲的最清楚，忍不住转载下。
原文如下：
认识CPU Cache
CPU Cache概述
随着CPU的频率不断提升，而内存的访问速度却没有质的突破，为了弥补访问内存的速度慢，充分发挥CPU的计算资源，提高CPU整体吞吐量，在CPU与内存之间引入了一级Cache。随着热点数据体积越来越大，一级Cache L1已经不满足发展的要求，引入了二级Cache L2，三级Cache L3。（注：若无特别说明，本文的Cache指CPU Cache，高速缓存）CPU Cache在存储器层次结构中的示意如下图：
计算机早已进入多核时代，软件也越来越多的支持多核运行。一个处理器对应一个物理插槽，多处理器间通过QPI总线相连。一个处理器包含多个核，一个处理器间的多核共享L3 Cache。一个核包含寄存器、L1 Cache、L2 Cache，下图是Intel Sandy Bridge CPU架构，一个典型的NUMA多处理器结构：
作为程序员，需要理解计算机存储器层次结构，它对应用程序的性能有巨大的影响。如果需要的程序是在CPU寄存器中的，指令执行时1个周期内就能访问到他们。如果在CPU Cache中，需要1~30个周期；如果在主存中，需要50~200个周期；在磁盘上，大概需要几千万个周期。充分利用它的结构和机制，可以有效的提高程序的性能。
以我们常见的X86芯片为例，Cache的结构下图所示：整个Cache被分为S个组，每个组是又由E行个最小的存储单元——Cache Line所组成，而一个Cache Line中有B（B=64）个字节用来存储数据，即每个Cache Line能存储64个字节的数据，每个Cache Line又额外包含一个有效位(valid bit)、t个标记位(tag bit)，其中valid bit用来表示该缓存行是否有效；tag bit用来协助寻址，唯一标识存储在CacheLine中的块；而Cache Line里的64个字节其实是对应内存地址中的数据拷贝。根据Cache的结构题，我们可以推算出每一级Cache的大小为B×E×S。
那么如何查看自己电脑CPU的Cache信息呢？
在windows下查看方式有多种方式，其中最直观的是，通过安装CPU-Z软件，直接显示Cache信息，如下图：
此外，Windows下还有两种方法：
①Windows API调用GetLogicalProcessorInfo。
②通过命令行系统内部工具CoreInfo。
如果是Linux系统， 可以使用下面的命令查看Cache信息：
ls /sys/devices/system/cpu/cpu0/cache/index0
还有lscpu等命令也可以查看相关信息,如果是Mac系统，可以用sysctl machdep.cpu 命令查看cpu信息。
如果我们用Java编程，还可以通过CacheSize API方式来获取Cache信息， CacheSize是一个谷歌的小项目，java语言通过它可以进行访问本机Cache的信息。示例代码如下：
public static void main(String[] args) throws CacheNotFoundException {
CacheInfo info = CacheInfo.getInstance()
CacheLevelInfo l1Datainf = info.getCacheInformation(CacheLevel.L1, CacheType.DATA_CACHE)
System.out.println("第一级数据缓存信息："+l1Datainf.toString())
CacheLevelInfo l1Instrinf = info.getCacheInformation(CacheLevel.L1, CacheType.INSTRUCTION_CACHE)
System.out.println("第一级指令缓存信息："+l1Instrinf.toString())
打印输出结果如下：
第一级数据缓存信息：CacheLevelInfo [cacheLevel=L1, cacheType=DATA_CACHE, cacheSets=64, cacheCoherencyLineSize=64, cachePhysicalLinePartitions=1, cacheWaysOfAssociativity=8, isFullyAssociative=false, isSelfInitializing=true, totalSizeInBytes=32768]
第一级指令缓存信息：CacheLevelInfo [cacheLevel=L1, cacheType=INSTRUCTION_CACHE, cacheSets=64, cacheCoherencyLineSize=64, cachePhysicalLinePartitions=1, cacheWaysOfAssociativity=8, isFullyAssociative=false, isSelfInitializing=true, totalSizeInBytes=32768]
还可以查询L2、L3级缓存的信息，这里不做示例。从打印的信息和CPU-Z显示的信息可以看出，本机的Cache信息是一致的，L1数据/指令缓存大小都为：C=B×E×S=64×8×64=32768字节=32KB。
Cache Line伪共享及解决方案
Cache Line伪共享分析
说伪共享前，先看看Cache Line 在java编程中使用的场景。如果CPU访问的内存数据不在Cache中（一级、二级、三级），这就产生了Cache Line miss问题，此时CPU不得不发出新的加载指令，从内存中获取数据。通过前面对Cache存储层次的理解，我们知道一旦CPU要从内存中访问数据就会产生一个较大的时延，程序性能显著降低，所谓远水救不了近火。为此我们不得不提高Cache命中率，也就是充分发挥局部性原理。
局部性包括时间局部性、空间局部性。时间局部性：对于同一数据可能被多次使用，自第一次加载到Cache Line后，后面的访问就可以多次从Cache Line中命中，从而提高读取速度（而不是从下层缓存读取）。空间局部性：一个Cache Line有64字节块，我们可以充分利用一次加载64字节的空间，把程序后续会访问的数据，一次性全部加载进来，从而提高Cache Line命中率（而不是重新去寻址读取）。
看个例子：内存地址是连续的数组（利用空间局部性），能一次被L1缓存加载完成。
如下代码，长度为16的row和column数组，在Cache Line 64字节数据块上内存地址是连续的，能被一次加载到Cache Line中，所以在访问数组时，Cache Line命中率高，性能发挥到极致。
public int run(int[] row, int[] column) {
int sum = 0;
for(int i = 0; i & 16; i++ ) {
sum += row[i] * column[i];
return sum;
而上面例子中变量i则体现了时间局部性，i作为计数器被频繁操作，一直存放在寄存器中，每次从寄存器访问，而不是从主存甚至磁盘访问。虽然连续紧凑的内存分配带来高性能，但并不代表它一直都能带来高性能。如果把它放在多线程中将会发生什么呢？如图：
数据X、Y、Z被加载到同一Cache Line中，线程A在Core1修改X，线程B在Core2上修改Y。根据MESI大法，假设是Core1是第一个发起操作的CPU核，Core1上的L1 Cache Line由S（共享）状态变成M（修改，脏数据）状态，然后告知其他的CPU核，图例则是Core2，引用同一地址的Cache Line已经无效了；当Core2发起写操作时，首先导致Core1将X写回主存，Cache Line状态由M变为I（无效），而后才是Core2从主存重新读取该地址内容，Cache Line状态由I变成E（独占），最后进行修改Y操作，
Cache Line从E变成M。可见多个线程操作在同一Cache Line上的不同数据，相互竞争同一Cache Line，导致线程彼此牵制影响，变成了串行程序，降低了并发性。此时我们则需要将共享在多线程间的数据进行隔离，使他们不在同一个Cache Line上，从而提升多线程的性能。
Cache Line伪共享处理方案
处理伪共享的两种方式：
增大数组元素的间隔使得不同线程存取的元素位于不同的cache line上。典型的空间换时间。（Linux cache机制与之相关）在每个线程中创建全局数组各个元素的本地拷贝，然后结束后再写回全局数组。
在Java类中，最优化的设计是考虑清楚哪些变量是不变的，哪些是经常变化的，哪些变化是完全相互独立的，哪些属性一起变化。举个例子：
public class Data{
long modifyT
long createT
int value;
假如业务场景中，上述的类满足以下几个特点：
当value变量改变时，modifyTime肯定会改变createTime变量和key变量在创建后，就不会再变化。flag也经常会变化，不过与modifyTime和value变量毫无关联。
当上面的对象需要由多个线程同时的访问时，从Cache角度来说，就会有一些有趣的问题。当我们没有加任何措施时，Data对象所有的变量极有可能被加载在L1缓存的一行Cache Line中。在高并发访问下，会出现这种问题：
如上图所示，每次value变更时，根据MESI协议，对象其他CPU上相关的Cache Line全部被设置为失效。其他的处理器想要访问未变化的数据(key 和 createTime)时，必须从内存中重新拉取数据，增大了数据访问的开销。
Padding 方式
正确的方式应该将该对象属性分组，将一起变化的放在一组，与其他属性无关的属性放到一组，将不变的属性放到一组。这样当每次对象变化时，不会带动所有的属性重新加载缓存，提升了读取效率。在JDK1.8以前，我们一般是在属性间增加长整型变量来分隔每一组属性。被操作的每一组属性占的字节数加上前后填充属性所占的字节数，不小于一个cache line的字节数就可以达到要求：
public class DataPadding{
long a1,a2,a3,a4,a5,a6,a7,a8;
int value;
long modifyT
long b1,b2,b3,b4,b5,b6,b7,b8;
long c1,c2,c3,c4,c5,c6,c7,c8;
long createT
long d1,d2,d3,d4,d5,d6,d7,d8;
通过填充变量，使不相关的变量分开
Contended注解方式
在JDK1.8中，新增了一种注解@sun.misc.Contended，来使各个变量在Cache line中分隔开。注意，jvm需要添加参数-XX:-RestrictContended才能开启此功能
用时，可以在类前或属性前加上此注释：
@sun.misc.Contended
@SuppressWarnings("restriction")
public class ContendedData {
long modifyT
long createT
或者这种：
@SuppressWarnings("restriction")
public class ContendedGroupData {
@sun.misc.Contended("group1")
@sun.misc.Contended("group1")
long modifyT
@sun.misc.Contended("group2")
@sun.misc.Contended("group3")
long createT
@sun.misc.Contended("group3")
采取上述措施图示：
JDK1.8 ConcurrentHashMap的处理
java.util.concurrent.ConcurrentHashMap在这个如雷贯耳的Map中，有一个很基本的操作问题，在并发条件下进行++操作。因为++这个操作并不是原子的，而且在连续的Atomic中，很容易产生伪共享（false sharing）。所以在其内部有专门的数据结构来保存long型的数据:
（openjdk\jdk\src\share\classes\java\util\concurrent\ConcurrentHashMap.java line:2506）：
* A padded cell for distributing counts.
Adapted from LongAdder
* and Striped64.
See their internal docs for explanation.
@sun.misc.Contended static final class CounterCell {
volatile long
CounterCell(long x) { value = }
我们看到该类中，是通过@sun.misc.Contended达到防止false sharing的目的
JDK1.8 Thread 的处理
java.lang.Thread在java中，生成随机数是和线程有着关联。而且在很多情况下，多线程下产生随机数的操作是很常见的，JDK为了确保产生随机数的操作不会产生false sharing ,把产生随机数的三个相关值设为独占cache line。
（openjdk\jdk\src\share\classes\java\lang\Thread.java line:2023）
/** The current seed for a ThreadLocalRandom */
@sun.misc.Contended("tlr")
long threadLocalRandomS
/** P nonzero if threadLocalRandomSeed initialized */
@sun.misc.Contended("tlr")
int threadLocalRandomP
/** Secondary seed isolated from public ThreadLocalRandom sequence */
@sun.misc.Contended("tlr")
int threadLocalRandomSecondaryS
Java中对Cache line经典设计
Disruptor框架
认识Disruptor
LMAX是在英国注册并受到FCA监管的外汇黄金交易所。也是欧洲第一家也是唯一一家采用多边交易设施Multilateral Trading Facility（MTF）拥有交易所牌照和经纪商牌照的欧洲顶级金融公司。LMAX的零售金融交易平台，是建立在JVM平台上，核心是一个业务逻辑处理器，它能够在一个线程里每秒处理6百万订单。业务逻辑处理器的核心就是Disruptor（注，本文Disruptor基于当前最新3.3.6版本），这是一个Java实现的并发组件，能够在无锁的情况下实现网络的Queue并发操作，它确保任何数据只由一个线程拥有以进行写访问，从而消除写争用的设计，
这种设计被称作“破坏者”，也是这样命名这个框架的。
Disruptor是一个线程内通信框架，用于线程里共享数据。与LinkedBlockingQueue类似，提供了一个高速的生产者消费者模型，广泛用于批量IO读写，在硬盘读写相关的程序中应用的十分广泛，Apache旗下的HBase、Hive、Storm等框架都有在使用Disruptor。LMAX 创建Disruptor作为可靠消息架构的一部分，并将它设计成一种在不同组件中共享数据非常快的方法。Disruptor运行大致流程入下图：
图中左侧（Input Disruptor部分）可以看作多生产者单消费者模式。外部多个线程作为多生产者并发请求业务逻辑处理器（Business Logic Processor），这些请求的信息经过Receiver存放在粉红色的圆环中，业务处理器则作为消费者从圆环中取得数据进行处理。右侧（Output Disruptor部分）则可看作单生产者多消费者模式。业务逻辑处理器作为单生产者，发布数据到粉红色圆环中，Publisher作为多个消费者接受业务逻辑处理器的结果。这里两处地方的数据共享都是通过那个粉红色的圆环，它就是Disruptor的核心设计RingBuffer。
Disruptor特点
无锁机制。没有CAS操作，避免了内存屏障指令的耗时。避开了Cache line伪共享的问题，也是Disruptor部分主要关注的主题。
Disruptor对伪共享的处理
RingBuffer类
RingBuffer类（即上节中粉红色的圆环）的类关系图如下：
通过源码分析，RingBuffer的父类，RingBufferFields采用数组来实现存放线程间的共享数据。下图，第57行，entries数组。
前面分析过数组比链表、树更具有缓存友好性，此处不做细表。不使用LinkedBlockingQueue队列，是基于无锁机制的考虑。详细分析可参考，并发编程网的翻译。这里我们主要分析RingBuffer的继承关系中的填充，解决缓存伪共享问题。如下图：
依据JVM对象继承关系中父类属性与子类属性，内存地址连续排列布局，RingBufferPad的protected long p1,p2,p3,p4,p5,p6,p7;作为缓存前置填充，RingBuffer中的protected long p1,p2,p3,p4,p5,p6,p7;作为缓存后置填充。这样任意线程访问RingBuffer时，RingBuffer放在父类RingBufferFields的属性，都是独占一行Cache line不会产生伪共享问题。如图，RingBuffer的操作字段在RingBufferFields中，使用rbf标识：
按照一行缓存64字节计算，前后填充56字节（7个long），中间大于等于8字节的内容都能独占一行Cache line，此处rbf是大于8字节的。
Sequence类
Sequence类用来跟踪RingBuffer和事件处理器的增长步数，支持多个并发操作包括CAS指令和写指令。同时使用了Padding方式来实现，如下为其类结构图及Padding的类。
Sequence里在volatile long value前后放置了7个long padding，来解决伪共享的问题。示意如图，此处Value等于8字节：
也许读者应该会认为这里的图示比上面RingBuffer的图示更好理解，这里的操作属性只有一个value，两个图相互结合就更能理解了。
Sequencer的实现
在RingBuffer构造函数里面存在一个Sequencer接口，用来遍历数据，在生产者和消费者之间传递数据。Sequencer有两个实现类，单生产者模式的实现SingleProducerSequencer与多生产者模式的实现MultiProducerSequencer。它们的类结构如图：
单生产者是在Cache line中使用padding方式实现，源码如下：
多生产者则是使用 sun.misc.Unsafe来实现的。如下图：
总结与使用示例
可见padding方式在Disruptor中是处理伪共享常见的方式，JDK1.8的@Contended很好的解决了这个问题，不知道Disruptor后面的版本是否会考虑使用它。
Disruptor使用示例代码。
7个示例科普CPU Cache：
Linux Cache 机制：
《深入理解计算机系统》：第六章部分
Disruptor官方文档：
Disruptor并发编程网文档翻译：
作者简介：
上海-周卫理、北京-杨珍琪、北京-冯英圣、深圳-姜寄羽 倾力合作，另外感谢惠普系统架构师吴治辉策划支持。
周卫理：本科，从事Java开发7年，热爱研究术问题，喜欢运动。目前就职于上海一家互联网公司，担任Java后端小组组长，负责分布式系统框架搭建。正往Java高性能编程，大数据中间件方向靠拢。
冯英胜：长期从事Java软件开发工作，善于复杂业务开发，6年工作经验，对大数据平台和分布式架构等有浓厚兴趣。目前就职于北京当当网。
姜寄羽：四川大学软件工程学士。目前在深圳亚略特担任Java工程师一职。负责Java方面的开发和维护以及新技术预研，对软件工程、分布式系统和高性能编程有着深厚的理论基础。
杨珍琪：硕士，会计学士，前HP工程师，参与中国移动BOSS系统开发，现为创业公司CTO。
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！}