大家好,我是王有志。关注王有志,一起聊技术,聊游戏,聊在外漂泊的生活。
今天我们学习并发编程中另一个重要的关键字volatile
,虽然面试中它的占比低于synchronized
,但依旧是不可忽略的内容。
关于volatile
,我收集到了8个常见考点,围绕应用,特点和实现原理。
1. volatile有什么作用?
2. 为什么多线程环境中会出现可见性问题?
3. synchronized和volatile有哪些区别?
4. 详细描述volatile的实现原理(涉及内存屏障)。
5. volatile有哪些特性?它是如何保证这些特性的?
6. volatile保证线程间变量的可见性,是否意味着volatile变量就是并发安全的?
7. 为什么方法中的变量不需要使用volatile?
8. 重排序是如何产生的?
复制代码
本文从volatile
应用开始,接着从源码角度分析volatile
的实现,通过对原理的剖析尝试解答以上问题。
volatile是什么
同synchronized
一样,volatile
是Java的提供的用于并发控制的关键字,不过它们之间也有比较明显的差异。
首先是使用方式:
-
synchronized
能够修饰方法和代码块 -
volatile
只能修饰成员变量
能力上volatile
也更“弱”一些:
-
保证被修饰变量的可见性
-
禁止被修饰变量发生指令重排
我们稍微修改关于线程你必须知道的8个问题(上)中可见性问题的代码,使用volatile
修饰变量flag
:
private static volatile boolean flag = true;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (flag) {
}
System.out.println("线程:" + Thread.currentThread().getName() + ",flag状态:" + flag);
}, "block_thread").start();
TimeUnit.MICROSECONDS.sleep(500);
new Thread(() -> {
flag = false;
System.out.println("线程:" + Thread.currentThread().getName() + ",flag状态:" + flag);
}, "change_thread").start();
}
复制代码
不难发现,block_thread解脱了,说明对flag
的修改被其它线程“看见了”,这就是volatile
保证可见性的表现。
接着修改《深入理解JMM和Happens-Before》中指令重排带来有序性问题的代码,同样使用volatile
修饰变量instance
:
public class Singleton {
static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized(Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
}
复制代码
多次实验后发现,不会再获取到未经初始化的instacne
对象了,这就是volatile
禁止指令重排的表现。
Tips:再次强调,Happens-Before描述的是行为结果间的关系。
volatile的实现
以下内容基于JDK 11 HotSpot虚拟机,以X86架构的实现为主,会与ARM架构的实现对比。选择这些的原因很简单,它们是各自领域的“顶流”。
volatile
使用简单,功能易理解,但往往简单的背后隐藏着复杂的实现。和分析synchronized
的过程一样,从字节码开始,再到JVM的实现,力求从底层串联volatile
,内存屏障与硬件之间的关系。
volatile
在不同架构下的实现差异较大,看个例子,X86架构的templateTable_x86中getfield_or_static
方法的实现:
void TemplateTable::getfield_or_static(int byte_no, bool is_static, RewriteControl rc) {
// 省略类型判断的代码
__ bind(Done);
// [jk] not needed currently
// volatile_barrier(Assembler::Membar_mask_bits(Assembler::LoadLoad | Assembler::LoadStore));
}
复制代码
ARM架构的templateTable_arm中getfield_or_static
方法的实现:
void TemplateTable::getfield_or_static(int byte_no, bool is_static, RewriteControl rc) {
// 省略类型判断的代码
__ bind(Done);
if (gen_volatile_check) {
Label notVolatile;
__ tbz(Rflagsav, ConstantPoolCacheEntry::is_volatile_shift, notVolatile);
volatile_barrier(MacroAssembler::Membar_mask_bits(MacroAssembler::LoadLoad | MacroAssembler::LoadStore), Rtemp);
__ bind(notVolatile);
}
}
复制代码
X86架构下不需要对volatile
类型进行特殊处理,而ARM架构下,添加内存屏障保证了与X86架构一致的效果。这个例子是为了展示规范在不同CPU架构上的实现差异,另外提醒大家不要误将X86的实现当成标准,X86架构对重排序的约束更强,能“天然”实现JMM规范中的某些要求,所以JVM层面的实现看起来会非常简单。
上面一直在说模板解释器,不过后面的内容我要用字节码解释器bytecodeInterpreter了。为什么不用模板解释器?因为模板解释器离OrderAccess太“远”了,而OrderAccess中内存屏障的详细解释是理解volatile
原理的关键。
不过,我们还是先花点时间了解下X86架构下内存屏障assembler_x86的实现:
enum Membar_mask_bits {
StoreStore = 1 << 3,
LoadStore = 1 << 2,
StoreLoad = 1 << 1,
LoadLoad = 1 << 0
};
void membar(Membar_mask_bits order_constraint) {
if (os::is_MP()) {
if (order_constraint & StoreLoad) {
int offset = -VM_Version::L1_line_size();
if (offset < -128) {
offset = -128;
}
lock();
addl(Address(rsp, offset), 0);
}
}
}
复制代码
使用位掩码定义内存屏障的枚举,分析偏向锁的时候就见到过位掩码的使用,重点在membar
方法中最后两行代码:
lock();
addl(Address(rsp, offset), 0);
复制代码
插入了lock addl
指令,它是X86架构下内存屏障实现的关键,orderAccess_linux_x86中的实现也是如此。
Tips:membar
方法是Memory Barrier(内存屏障)的缩写,另外也有称为Memory Fence(内存栅栏)的,或者直接称为fence,反正屏障,栅栏什么的乱七八糟的。
从字节码开始
使用双检锁单例模式生成的字节码:
public class com.wyz.keyword.keyword_volatile.Singleton
static volatile com.wyz.keyword.keyword_volatile.Singleton instance;
flags:(0x0048) ACC_STATIC, ACC_VOLATILE
public static com.wyz.keyword.keyword_volatile.Singleton getInstance();
Code:
stack=2, locals=2, args_size=0
24: putstatic #7 // Field instance:Lcom/wyz/keyword/keyword_volatile/Singleton;
37: getstatic #7 // Field instance:Lcom/wyz/keyword/keyword_volatile/Singleton;
复制代码
我们看字节码中的关键部分:
-
标记
volatile
变量的ACC_VOLATILE
; -
写入/读取静态变量时的指令
getstatic
和putstatic
。
Java 11虚拟机规范第4章中是这样描述ACC_VOLATILE
的:
ACC_STATIC 0x0008 Declared static.
ACC_VOLATILE 0x0040 Declared volatile; cannot be cached.
虚拟机规范要求被volatile
修饰的变量不能被缓存。我们知道,CPU高速缓存是带来可见性问题的“罪魁祸首”,不能被缓存就意味着杜绝了可见性问题,但并不意味着不使用缓存。
Java 11虚拟机规范第6章中也描述了getstatic
指令的作用:
Get static field from class.
putstatic
指令的作用:
Set static field in class.
可以大致猜到JVM的实现volatile
的方式,JVM中定义getstatic
/putstatic
指令对应的方法,并在方法中判断变量是否被标记为ACC_VOLATILE
,然后进行特殊逻辑处理。
Tips:
-
0x0048是
ACC_STATIC
和ACC_VOLATILE
结合的结果; -
非
static
变量,读取和写入是getfield
和putfield
两条指令。
字节码解释器的实现
这部分我们只看putstatic
的源码,前面模板解释器的部分也大致分析了getstatic
,剩下的就留给大家自行分析了。
putstatic
的实现在bytecodeInterpreter中第2026行:
CASE(_putfield):
CASE(_putstatic):
{
if ((Bytecodes::Code)opcode == Bytecodes::_putstatic) {
// static的处理方式
} else {
// 非static的处理方式
}
// ACC_VOLATILE -> JVM_ACC_VOLATILE -> is_volatile()
if (cache->is_volatile()) {
// volatile变量的处理方式
if (tos_type == itos) {
obj->release_int_field_put(field_offset, STACK_INT(-1));
}else {
// 省略了超多的类型判断
}
OrderAccess::storeload();
} else {
// 非volatile变量的处理方式
}
}
复制代码
逻辑很简单,判断变量的类型,然后调用OrderAccess::storeload()
,保证volatile
变量的特性实现。
JVM的内存屏障
JVM在不同操作系统,CPU架构的基础上,构建了一套符合JMM规范的内存屏障,屏蔽了不同架构间的差异,实现了内存屏障的语义一致性。这部分重点解释JVM实现的4种主要内存屏障和介绍X86架构的实现以及硬件差异导致的不同。
来看orderAccess中对4种内存屏障的解释:
Memory Access Ordering Model
LoadLoad: Load1(s); LoadLoad; Load2
Ensures that Load1 completes (obtains the value it loads from memory) before Load2 and any subsequent load operations. Loads before Load1 may not float below Load2 and any subsequent load operations.
StoreStore: Store1(s); StoreStore; Store2
Ensures that Store1 completes (the effect on memory of Store1 is made visible to other processors) before Store2 and any subsequent store operations. Stores before Store1 may not float below Store2 and any subsequent store operations.
LoadStore: Load1(s); LoadStore; Store2
Ensures that Load1 completes before Store2 and any subsequent store operations. Loads before Load1 may not float below Store2 and any subsequent store operations.
StoreLoad: Store1(s); StoreLoad; Load2
Ensures that Store1 completes before Load2 and any subsequent load operations. Stores before Store1 may not float below Load2 and any subsequent load operations.
努力翻译下对4种主要的内存屏障的描述:
-
LoadLoad,指令:
Load1; LoadLoad; Load2
。确保Load1在Load2及之后的读操作前完成读操作,Load1前的Load指令不能重排序到Load2及之后的读操作后; -
StoreStore,指令:
Store1; StoreStore; Store2
。确保Store1在Store2及之后的写操作前完成写操作,且Stroe1写操作的结果对Store2可见,Store1前的Store指令不能重排序到Store2及之后的写操作后; -
LoadStore,指令:
Load1; LoadStore; Store2
。确保Load1在Store2及之后的写操作前完成读操作,Load1前的Load指令不能重排序到Store2及之后的写操作后; -
StoreLoad:指令:
Store1; StoreLoad; Load2
。确保Store1在Load2及之后的Load指令前完成写操作,Store1前的Store指令不能重排序到Load2及之后的Load指令后。
虽然翻译过来有些拗口,但理解起来并不困难,建议小伙伴们认真阅读这部分注释(包括后面的内容)。
注释中可以看出,内存屏障保证了程序的有序性。
X86架构的内存屏障实现
Linux平台X86架构的实现orderAccess_linux_x86中对内存屏障的定义:
inline void OrderAccess::loadload() { compiler_barrier(); }
inline void OrderAccess::storestore() { compiler_barrier(); }
inline void OrderAccess::loadstore() { compiler_barrier(); }
inline void OrderAccess::storeload() { fence(); }
inline void OrderAccess::acquire() { compiler_barrier(); }
inline void OrderAccess::release() { compiler_barrier(); }
复制代码
实现非常简单,只有两个核心方法compiler_barrier
和fence
:
static inline void compiler_barrier() {
__asm__ volatile ("" : : : "memory");
}
inline void OrderAccess::fence() {
// always use locked addl since mfence is sometimes expensive
#ifdef AMD64
__asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
__asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
compiler_barrier();
}
复制代码
上述代码是GCC的扩展内联汇编形式,简单解释下compiler_barrier
方法中的内容:
-
asm,插入汇编指令;
-
volatile,禁止优化此处的汇编指令;
-
meomory,汇编指令修改了内存,要重新读取内存数据。
接着是支撑storeload屏障的fence
方法,和templateTable_x86的实现一样,核心是lock addl
指令。lock前缀指令可以理解为CPU指令级的锁,对总线和缓存加锁,主要有两个作用:
-
Lock前缀指令会引起处理器缓存回写到内存
-
处理器缓存回写到内存会导致其他处理器的缓存无效
实际上X86架构提供了内存屏障指令lfence,sfence,mfence等,但为什么不使用内存屏障指令呢?原因在fence
的注释中:
mfence is sometimes expensive
即mfence
指令在性能上的开销较大。
好了,到这里我们已经能够得到X86架构下实现volatile
特性的原理:
-
JVM的角度看,内存屏障提供了可见性和有序性的保证;
-
X86的角度看,
voaltile
指令禁止重排序,Lock
指令引起缓存失效和回写。
Tips:fence
方法中AMD64和X86的处理略有差异,关于它们的渊源,可以参考pansz大佬的知乎。
其他架构实现差异的原因
前面看到,X86架构和ARM架构的模板解释器中,getfield_or_static
方法在使用内存屏障上产生了分歧,ARM通过内存屏障到达了“罗马”,而X86出生在“罗马”。
不难想到产生这种差异的原因,CPU架构对重排序的约束不同,导致JVM需要使用不同的处理方式达到统一的效果。关于CPU允许的重排序,我“搬运”了一张图: