volatile

I have a thread: class Foo extends Thread { boolean active = true; public void run() { while(active) { //do stuff } } public void end() { active = false; } public void hibernate() { synchronized(this) { wait(); } } } If another thread calls end() , will Foo immediately see that active is now false ? Specifically, because active isn't volatile , I'm not sure that it will. I initially created end() as a clever way of avoiding volatile, but now I'm unsure that it will actually do what I intend. Additionally, if another thread calls hibernate() , which thread will go to sleep? I'm intending Foo to

I found this in a multi-threaded c application. The authors commented that it's used to make a thread crash in a custom assert function. GCC is fine with it, but clang issues the following warning: note: consider using __builtin_trap() or qualifying pointer with 'volatile' and also issues one of those, for each usage of the assert function: warning: indirection of non-volatile null pointer will be deleted, not trap What is going on here? Is __builtin_trap specific to clang? Should I use it? Writing to NULL address is not guaranteed to crash your program reliably, so GCC introduced __builtin

is final Map<Integer,Map<String,Integer>> status = new ConcurrentHashMap<Integer, Map<String,Integer>>(); Map<Integer,Map<String,Integer>> statusInner = new ConcurrentHashMap<Integer, Map<String,Integer>>(); status.put(key,statusInner); the same as volatile Map<Integer,Map<String,Integer>> status = new ConcurrentHashMap<Integer, Map<String,Integer>>(); Map<Integer,Map<String,Integer>> statusInner = new ConcurrentHashMap<Integer, Map<String,Integer>>(); status.put(key,statusInner); in case the inner Map is accessed by different Threads? or is even something like this required: volatile Map

多线程的可见性 　　一、深入探究多线程的不确定性因素 1 1、cpu高速缓存导致的极短时间内获取不到想要数据 2 2、cpu指令重排导致之后的自行优化导致数据混乱；当然，这种情况值存在于多线程的基础上，单个线程是不会出现这种问题的。 3 3、JIT会把多次方法区中多调用或者多次循环的数据进行换存，然后自行优化；这里缓存也会导致后来改变的数据无法被正常的获取。 　　首先来说cpu的高速缓存，它是介于我们物理内存与程序之间。 　　CPU高速缓存（英语：CPU Cache，在本文中简称缓存）是用于减少 处理器 访问内存所需平均时间的部件。在金字塔式存储体系中它位于自顶向下的第二层，仅次于CPU寄存器。 　　其容量远小于 内存 ，但速度却可以接近处理器的频率。 　　当处理器发出内存访问请求时，会先查看缓存内是否有请求数据。如果存在（命中），则不经访问内存直接返回该数据；如果不存在（失效）， 则要先把内存中的相应数据载入缓存，再将其返回处理器。 　　缓存之所以有效，主要是因为程序运行时对内存的访问呈现局部性（Locality）特征。这种局部性既包括空间局部性（Spatial Locality），也包括时间局部性（Temporal Locality）。 　　有效利用这种局部性，缓存可以达到极高的命中率。 　　在处理器看来，缓存是一个透明部件。因此，程序员通常无法直接干预对缓存的操作。但是

传统的spinlock 　　Linux的的内核最常见的锁是自旋锁。自旋锁最多只能被一个可执行线程持有。如果一个执行线程试图获得一个被已经持有（争用）的自旋锁，那么该线程就会一直进行忙循环-旋转-等待锁重新可用要是锁未被争用，请求锁的执行线程就可以立即得到它，继续执行。在任意时间，自旋锁都可以防止多于一个的执行线程同时进入临界区。同一个锁可以用在多个位置，例如，对于给定数据的所有访问都可以得到保护和同步。 　　自旋锁在同一时刻至多被一个执行线程持有，所以一个时刻只有一个线程位于临界区内，这就为多处理器机器提供了防止并发访问所需的保护机制。在单处理机器上，编译的时候不会加入自旋锁，仅会被当作一个设置内核抢占机制是否被启用的开关。如果禁止内核抢占，那么在编译时自旋锁就会被剔除出内核。 　　传统的自旋锁本质上用一个整数来表示，值为1代表锁未被占用, 为0或者为负数表示被占用。 　　在 单处理机环境 中可以使用特定的原子级汇编指令 swap 和 test_and_set 实现进程互斥，（Swap指令：交换两个内存单元的内容；test_and_set指令取出内存某一单元(位)的值，然后再给该单元(位)赋一个新值） 这些指令涉及对同一存储单元的两次或两次以上操作，这些操作将在几个指令周期内完成，但由于中断只能发生在两条机器指令之间，而同一指令内的多个指令周期不可中断

volatile bool flag; volatile int a; 添加 volatile 限定符的变量会获得几个特性： 1.强制内存读取 因为这个数据是“易变的（volatile）”，所以要时刻关注，不能偷懒 场景： 把内存中的变量拷贝到寄存器中进行处理以加快速度； 存在的问题： 是对变量的拷贝进行处理，而变量本体如果发生变化可能也不会察觉 解决： 加上 volatile 限定符后，每次处理都会直接从内存读取，所以可以感知变量的变化。 但是： 寄存器走了，缓存来了，但问题没那么严重 多核cpu分别有自己的缓存，对内存的操作会先通过缓存，在一个cpu对volatile变量进行操作后，会告知其他cpu对其缓存进行处理以更新该volatile变量的值，这个告知并处理的流程会损失一点实时性。 2.禁止编译优化 “聪明的”编译器在满足“同输入便会同输出”的as-if原则的前提下，会在编译的过程中对代码进行优化，使得和输出无关的代码可能被优化掉，而如果这部分代码是有意义的，便是个问题。在加上限定符后，会老老实实地编译这部分代码。 注意：volatile不代表能够保证线程同步 加上该限定符后，编译的代码不会乱序，但是执行时可能碰到CPU的乱序执行，即 CPU会对没有明显依赖关系的代码进行乱序执行，但这段代码可能在另一个线程里存在依赖关系，导致原本设计好的逻辑关系不能实现。 此时可以适用c+

Consider this code example: int main(void) { volatile int a; static volatile int b; volatile int c; c = 20; static volatile int d; d = 30; volatile int e = 40; static volatile int f = 50; return 0; } Without volatile a compiler could optimize away all the variables since they are never read from. I think a and b can be optimized away since they are completely unused, see unused volatile variable . I think c and d can not be removed since they are written to, and writes to volatile variables must actually happen. e should be equivalent to c . GCC does not optimize away f , but it also does not

There are a few questions on this subject, but most skirt around this issue because it's not the intent of the question. If I have a static volatile in my class: private static volatile MyObj obj = null; and in a method below I do: public MyObj getMyObj() { if (obj == null) { obj = new MyObj();// costly initialisation } return obj; } will I need to synchronize to ensure only one thread writes to the field, or will any writes be immediately visible to other threads evaluating the obj == null conditional? To put it another way: does volatile get you around having to synchronize access to writes

volatile是jvm提供的轻量级的同步机制 保证可见性（一个线程的修改对其它线程是可见的） 不保证原子性 禁止指令重排序 什么是指令重排？ 计算机在执行程序时，为了提高性能，编译器和处理器会对指令做重排，过程如下 源代码--》编译器优化的重排--》指令并行的重排--》内存系统的重排--》最终执行的指令 处理器在进行重排时必须考虑数据之间的依赖性 单线程环境下重拍后执行的结果与代码顺序执行的结果一致 多线程环境下线程交替进行，由于编译器优化重排的存在，两个线程使用的变量能否保证一致性无法确定 /** * 如果有两个线程 * 一个执行fun1，一个执行fun2 * 1. 当fun1中语句一和语句二执行时发生指令重排，语句二在语句一之前执行 * 那么语句二执行完后，没等语句一执行，fun2中执行，a=5 * 2. 语句一先执行时，最后a=6 * 所以多线程环境下，由于编译器的优化重排，结果不确定 * <p> * volatile会禁止指令重排，让执行顺序按照代码编写的顺序执行 */ class ResortedDemo { int a; boolean flag; public void fun1() { a = 1;//语句一 flag = true;//语句二 } public void fun2() { if (flag) { a = a + 5; System.out

Whilst writing this answer I realised that I'm not as confident about my conclusions as I usually would ensure before hitting Post Your Answer . I can find a couple of reasonably convincing citations for the argument that the trivial-copyability of volatile data members is either implementation-defined or flat-out disallowed: https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/5cWxmw71ktI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48118 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#496 But I haven't been able to back this up in the standard 1 itself. Particularly