Java8中@Contended和伪共享

最新推荐文章于 2025-02-22 16:24:47 发布

Andy__Han

最新推荐文章于 2025-02-22 16:24:47 发布

阅读量9.9k

点赞数 8

Java8引入了@Contended注解以减少伪共享的影响。伪共享是指多个线程因访问同一缓存行而产生的性能损耗。文章介绍了缓存行的概念、伪共享的原因及其解决方案，包括使用填充技术及@Contended注解。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

@Contended和伪共享

原文：http://jingege.me/2016/05/31/sharing-false-and-contented/

原文: http://robsjava.blogspot.com/2014/03/what-is-false-sharing.html

Java8引入了@Contented这个新的注解来减少伪共享(False Sharing)的发生。本文介绍了@Contented注解并解释了为什么False Sharing是如何影响性能的。

缓存行

CPU读取内存数据时并非一次只读一个字节，而是会读一段64字节长度的连续的内存块(chunks of memory)，这些块我们称之为缓存行(Cache line)。

假设你有两个线程(Thread1和Thread2)都会修改同一个volatile变量x:

1	volatile long x;

如果Thread1先改变x的值，然后Thread2又去读它：

1 2	Thread 1: x= 3; Thread 2: System.out.print(x);

那么x所在缓存行上的所有64个字节的值都要被重新加载，因为CPU核心间交换数据是以缓存行为最小单位的。当然Thread1和Thread2是有可能在同一个核心上运行的，但我们此处假设两个线程在不同的核心上运行。

已知long类型占8个字节，缓存行长度为64个字节，那么一个缓存行可以保存8个long型变量，我们已经有了一个long型的x，假设x所在缓存行里还有其他7个long型变量，v1到v7:

1	x, v1, v2, v3, v4, v5 , v6 , v7

伪共享(False Sharing)

这个缓存行可以被许多线程访问。如果其中一个修改了v2，那么会导致Thread1和Thread2都会重新加载整个缓存行。你可能会疑惑为什么修改了v2会导致Thread1和Thread2重新加载该缓存行，毕竟只是修改了v2的值啊。虽然说这些修改逻辑上是互相独立的，但同一缓存行上的数据是统一维护的，一致性的粒度并非体现在单个元素上。这种不必要的数据共享就称之为“伪共享”(False Sharing)。

填充(Padding)

一个CPU核心在加载一个缓存行时要执行上百条指令。如果一个核心要等待另外一个核心来重新加载缓存行，那么他就必须等在那里，称之为stall(停止运转)。减少伪共享也就意味着减少了stall的发生，其中一个手段就是通过填充(Padding)数据的形式，来保证本应有可能位于同一个缓存行的两个变量，在被多线程访问时必定位于不同的缓存行。

在下面这个例子里，我们试图通过填充的方式，使得x和v1位于不同的缓存行：

      
       public 
       class FalseSharingWithPadding {
      
          
       public 
       volatile 
       long x;
      
          
       public 
       volatile 
       long p2;   
       // padding
      
          
       public 
       volatile 
       long p3;   
       // padding
      
          
       public 
       volatile 
       long p4;   
       // padding
      
          
       public 
       volatile 
       long p5;   
       // padding
      
          
       public 
       volatile 
       long p6;   
       // padding
      
          
       public 
       volatile 
       long p7;   
       // padding
      
          
       public 
       volatile 
       long p8;   
       // padding
      
          
       public 
       volatile 
       long v1;
      
      
       }

在你考虑使用填充之前，必须要了解的一点是JVM可能会清除无用字段或重排无用字段的位置，这样的话，可能无形中又会引入伪共享。我们也没有办法指定对象在堆内驻留的位置。

为了避免无用字段被消除，通常我们会用volatile修饰一下。个人建议只需为处于激烈竞争状态的类进行填充处理，而且一般只有通过对其性能分析才能发现性能上的不同。通常在性能分析时，最好在对其迭代访问10000次之后再去采样，这样可以消除JVM本身的运行时优化策略带来的影响。

Java8和@Contended

除了对字段进行填充之外，还有一个比较清爽的方法，那就是对需要避免陷入伪共享的字段进行注解，这个注解暗示JVM应当将字段放入不同的缓存行，这也正是JEP142的相关内容。

该JEP引入了@Contented注解。被这个注解修饰的字段应当和其他的字段驻留在不同的位置。

      
       public 
       class Point {
      
          
       int x;
      
          
       @Contended
      
          
       int y;
      
      
       }