JVM伪共享
来源:互联网 发布:笨办法学python百度云 编辑:程序博客网 时间:2024/05/18 03:04
伪共享False sharing说明JVM底层技术也不让人那么放心。内存缓存系统中基本单元是高速缓存行(Cache lines). cpu会把数据从内存加载到高速缓存中 ,这样可以获得更好的性能,高速缓存默认大小是64 Byte为一个区域,一个区域在一个时间点只允许一个核心操作,也就是说不能有多个核心同时操作一个缓存区域。
因为高速缓存是64字节,而Hotspot JVM的对象头是两个部分组成,第一部分是由24字节的hash code和8字节的锁等状态标识组成,第二部分是指向该对象类的引用。基本类型字节如下:
doubles (8) and longs (8)
ints (4) and floats (4)
shorts (2) and chars (2)
booleans (1) and bytes (1)
references (4/8)
因此,一个高速缓存64字节可以放下多个字段,如果这多个字段位于同一个高速缓存区,虽然它们是类的不同字段,如下代码:
Class A{ int x; int y;}
x和y被放在同一个高速缓存区,如果一个线程修改x;那么另外一个线程修改y,必须等待x修改完成后才能实施。
虽然两个线程修改各种独立变量,但是因为这些独立变量被放在同一个高速缓存区,性能就影响了。测试结果如后面。
当多核CPU线程同时修改在同一个高速缓存行各自独立的变量时,会不自不觉地影响性能,这就发生了伪共享False sharing,伪共享是性能的无声杀手。
解决方便是将高速缓存剩余的字节填充填满(pad),确保不发生多个字段被挤入一个高速缓存区,下面测试结果图就是和填充后性能比较。
实现字节填充的框架有 Disruptor,在RingBuffer中实现填充。关于Disruptor可见infoQ这个视频,用1毫秒的延时得到100K+ TPS吞吐量,JDK的ArrayQueue并行环境不见得是最快的,该视频后面讨论很多,让人大跌眼镜啊,开放源码多有好处啊,别人能发现你不能发现的漏洞。另外一篇解剖Disruptor
JVM伪共享
Disruptor系列文档
Martin Fowler的LMAX架构
https://github.com/LMAX-Exchange/disruptor/wiki/Getting-Started
Disruptor为什么这么快?锁是坏的
0 0
- JVM伪共享
- JVM伪共享
- JVM 伪共享
- JVM伪共享
- 伪共享
- 伪共享
- 共享与伪共享
- 伪共享false sharing
- cpu伪共享问题
- java 伪共享
- 伪共享(False Sharing)
- 伪共享(False Sharing)
- CPU伪共享
- java 伪共享
- 伪共享(False Sharing)
- JAVA之伪共享
- cpu伪共享问题
- 伪共享(False Sharing)
- 直接插入排序
- Oracle动态性能表-(5)-V$SQL,V$SQL_PLAN
- JAVA中UDP接受与发送数据初步步骤
- 解决ASM问题“Initializing the Oracle ASMLib driver: failed”
- map javascript小测试---GIS
- JVM伪共享
- websphere8 调整堆内存
- iOS 之Quartz2D渐变颜色填充
- Centos搭建Python+Nginx+Tornado+Mysql环境
- 数据库的存储引擎和SQL语言
- 安装mysql时报错:mysql file /usr/share/mysql/czech/errmsg.sys from install of MySQL-serve的问题
- c中多维数组及数组指针的理解
- Redis集群 官方教程
- Spring 报错记录1