由一个简单的例子引出并发处理时容易被忽视的陷阱，用来作为面试问题应该很适合。
 
某日，工作了 4 年多的 Java 程序员小 K 跳槽，面试时碰到这样一个题目…
 
public class P1 {
	private long b = 0;
	
	public void set1() {
		b = 0;
	}
	
	public void set2() {
		b = -1;
	}
	
	public void check() {
		System.out.println(b);
	
		if (0 != b && -1 != b) {
			System.err.println("Error");
		}
	 }
}

 
问题
 
调用 set1()、set2()、check()，会打印出 Error 么？
 
小K 的推理
 
“无论如何调用 set1()、set2() -> b 的值只可能是 0 或 -1 -> 在 check() 里面的判断条件（b 既不为 0 也不为 -1）永远不成立 -> 不打印 Error”
 
小 K 觉得有坑：这题目应该不会这么简单，再考虑一下多线程环境。
 
思前想后，小 K 得出结论：“在多线程环境下也不会打印 Error。这题目很简单，就是考察一下推理吧。”，K 暗自窃喜。
 
后来小 K 陆续又被问了几个多线程和 JVM 的问题。
 
后来，就没有后来了…
 
后来
 
后来还是有的。到家后，不甘心的小 K 验证了这道秒杀他的面试题。
 
public static void main(final String[] args) {
		final P1 v = new P1();
		// 线程 1：设置 b = 0
		final Thread t1 = new Thread() {
			public void run() {
				while (true) {
					v.set1();
				}
			};
		};
		t1.start();
	
		// 线程 2：设置 b = -1
		final Thread t2 = new Thread() {
			public void run() {
				while (true) {
					v.set2();
				}
			};
		};
		t2.start();
	
		// 线程 3：检查 0 != b && -1 != b
		final Thread t3 = new Thread() {
			public void run() {
				while (true) {
					v.check();
				}
			};
		};
		t3.start();
	}
 
使用 3 个线程分别重复执行 set1()、set2()、check()。执行输出结果部分如下：
 
....
0
0
1
1
1
Error
Error
-4294967296
0
0
4294967295
....
 
执行环境：
 Java™ SE Runtime Environment (build 1.6.0_31-b05)
 Java HotSpot™ Client VM (build 20.6-b01, mixed mode, sharing), 32bit
 
“确实打印了 Error，并且打印了 4294967295、-4294967296。我勒个去，只是啥情况？”
 
小 K 决定搞懂其中奥秘，重新审视了题目。以一个专业程序员的严谨，并经过无数次 Google 后…他似乎发现了问题所在。
 
“这确实是一个并发问题！”
 
分析
 
这道题目有两个陷阱，分别考察了对并发执行的理解，以及对 JVM 基础（赋值操作）的掌握。
 
陷阱一：并发执行
 
并发执行就是多个操作一起执行，CPU 执行不同上下文（可理解为不同线程）发过来的指令。操作系统上层看上去就像是并行处理一样。
 
也就是说，在编程语言层面，一个简单的操作同样需要考虑并发问题。
 
小 K 首先是栽在了 check() 中的 if 判断上和设值是存在并发的，不能保证 0 != b 这个判断真（此时 b 为 -1）后恰好 b 被赋值为 0 时判断 1 != b。
 
除此外，无论 JVM、操作系统、CPU 层面对指令如何优化、重排，最终都是逐一执行单一指令，唯一不同的就是不同层面可能会对执行加以限制，
 
比如加入原子操作，最终保证 CPU 能够完整执行一组指令。
 
陷阱二：JVM 赋值操作
 
一些赋值操作不是原子性的。“纳尼？”
 
Java 基础类型中，long 和 double 是 64 位长的。32 位架构 CPU 的算术逻辑单元（ALU）宽度是 32 位的，在处理大于 32 位操作时需要处理两次。
 
“这不是<计算机组成原理与汇编>么”，小 K 顿时感到大学白上了，不懂学以致用 T_T~
 
题目执行打印 4294967295、-4294967296 就是因为读时高 32 位或低 32 位被其他写覆盖了（看一下这两个数字的二进制就知道了）。
 
Java 已经是封装底层细节很好的语言了，但依然需要注意这些陷阱，可以使用并发处理包 java.util.concurrent.atomic 中包含了一系列无锁原子操作类型，
 
也可以使用 volatile 关键字保证线程间变量的可见性。
 
其实这道题目只要解决了并发问题，也就保证了每个执行单元（set1()、set2()、check()）中赋值、比较的正确性。可以把同步方法执行看作序列化的事务，各中操作不会相互影响。
 
再后来
 
虽然小 K 面试挂了，不过他挂得心服口服。
 
通过这个期间的不断翻阅文档以及实验，小 K 下次的面试应该不会被类似的题目秒杀了吧…
 
“按照这个简单面试题的标准，以前写过的程序简直就是通篇 bugs 啊！有木有，有木有啊！！！！”
 
骚年，继续充电吧！
 
内外兼修才是好程序员 😃
 
 
 
在64位os下测了下，楼主的程序不会打印ERROR，我猜测大概原因如下：
 1）long是64位的问题。在32位os写高32位和低32位的问题，在64位机器貌似没有问题
 2）if的两个判断的问题。因为线程有自己的堆栈和寄存器，线程3在if读到b之后，第二次貌似就从自己的寄存器读取了
 把“private long b = 0;” 改成 “private volatile long b = 0;” 之后，就能打印ERROR了，原理是volatile要求线程每次都去内存读取b
 大家不信可以试试，实验是检验真理的唯一标准
 

目录
 
•写在前面
 
•原子性
 
加锁机制
 

•写在前面
 
进程想要执行任务需要依赖线程，换句话说就是进程中的最小执行单位就是线程，并且一个进程中至少有一个线程。提到多线程这里要说两个概念，就是串行和并行，搞清楚这个我们才能更好的理解多线程。所谓串行其实是相对于单条线程来执行多个任务来说的，我们就拿下载文件来举个例子，我们下载多个文件，在串行中它是按照一定的顺序去进行下载的，也就是说必须等下载完A之后，才能开始下载B，它们在时间上是不可能发生重叠的。
 
要编写线程安全的代码，其核心在于要对状态访问操作进行管理，特别是对共享的和可变的状态的访问。要是的对象是线程安全的，需要采用同步机制来协同对对象可变状态的访问，如果无法实现协同，那么可能会导致数据破坏以及其他不该出现的结果。java中的同步机制是关键字synchronized，它提供了独占式的加锁方式，不仅如此还包括volatile类型变量，显式锁Lock以及原子变量。
 
单线程近似定义为“所见即所知”，那么定义线程安全性，则当多个线程访问某个类时，这个类始终都能表现出正确的行为，那么就称这个类是线程安全的。一个类在单线程中运行都不正确，那么它肯定是不会是线程安全的。如果正确的实现了某个对象，那么在任何操作中（包括调用对象的公有方法或者对其公有域进行读写操作）都不会违背不变性条件或后验条件。在线程安全类的对象实例上执行的任何串行或并行操作都不会处于无效状态。
 
无状态的对象一定是安全的，啥是无状态？这个类既不包括任何域，也不包括任何对其他类中域的引用。举个例子，大多数Servlet都是无状态的，从而极大的降低了在实现Servlet线程安全性时的复杂性，只有当Servlet在处理请求时需要保存一些信息，线程安全性才会成为一个问题。
 
•原子性
 
其实原子性就是一个不可分割的，我们怎么理解呢？举个例子，当我们在无状态对象中增加一个状态时，会发生什么情况？比我们要计算一个类调用了多少次（这个类可以是Servlet），我们定义一个私有的Long类型的域（命名为count），在方法中没调用一次就将这个值加一（即count++），如下。
 
   Integer count = 0;
   public void getCount() {
       count ++;
       System.out.println(count);
   }
 
由于我们没有对这个类进行任何的同步机制操作，所以这个类是非线程安全的，虽然在单线程环境中能正确运行，但在多线程情况下就会出现问题。我们注意到count++这个操作，这个操作看上去是一个操作，其实这个操作并非原子性的，因为它并不会作为一个不可分割的操作来执行，实际上count++ 包含了三个独立的操作，分为读取count的值，将值加1，然后计算结构写入count中，这是一个“读取-修改-写入”的操作序列，并且其结果依赖于之前的状态。在并发下就会出现问题，我再多线程下跑了上面那段代码，结果如下
 
 
我们可以看到，这里出现了两个26，为什么会出现这种情况，出现这种情况显然表明我们这个方法根本就不是线程安全的，出现这种问题的原因有很多，我们说最常见的一种，就是我们A线程在进入方法后，拿到了count的值，刚把这个值读取出来还没有改变count的值的时候，结果线程B也进来的，那么导致线程A和线程B拿到的count值是一样的。
 
在并发编程中，这种由于不恰当的执行时序而出现不正确的结果是一种非常重要的情况，它有一个正式的名字，叫“竞态条件”。竞态条件是啥？当某个计算的正确性取决于多个线程的交替执行时序时，那么就会发生竞态条件，最常见的竞态条件类型就是“先检查后执行”操作，即通过一个可能失效的观察结果来决定下一步的动作。比如首先观察到某个条件为真（例如文件X不存在），然后根据这个观察结果采用相应的动作（创建文件X），但事实上，在你观察到这个结果以及开始创建文件之间，观察结果可能变得无效（另一个线程在这个期间创建了文件X），从而导致各种问题（未预期的异常、数据覆盖、文件被破坏等）。
 
与大多数并发错误一样，竞态条件并不总是会产生错误，还需要某种不恰当的执行时序。原子操作是对于访问同一个状态的所有操作（包括该操作本身）来说，这个操作是一个以原子方式执行的操作。而我们前面提到的类似count++的这种操作，叫做复合操作，即包含了一组必须以原子方式执行的操作以确保线程安全性。在实际情况中，应该尽可能的使用现有的线程安全对象来管理类的状态，与非线程安全的对象相比，判断线程安全对象的可能状态及其状态转换情况要更为容易，从而也更容易维护和验证线程安全性。这里值得一提的是，java中给我们弄好了很多原子操作的类型，在这个包下java.util.concurrent.atomic。
 
加锁机制
 
上面我们说了，我们可以对单个类进行原子性操作，这样可以保证我们程序的安全性，但是，我们想一想，如果当多个原子性的操作同时进行时，而且各个原子性操作之间都存在相互依赖的关系，这种情况下，我们怎么保证程序运行正确（线程安全）？如果还是使用原子性操作的方法，那么我们要保持状态的一致性，就需要在单个原子操作中更新所有相关的状态变量。
 
说到这里，我们就不得不提一下java提供的一种内置的锁机制来支持原子性，即同步代码块（synchronized block），同步代码快包括两部分，一个作为锁的对象引用，一个作为由这个锁保护的代码块。以关键字synchronized来修饰的方法就是一种横跨整个方法体的同步代码块，其中该同步代码块的锁就是方法调用所在的对象。每个Java对象都可以用作一个实现同步的锁，这些所被称为内置锁或监视器锁。线程在进入同步代码块之前会自动获得锁，并且在退出同步代码块时自动释放锁，这里要说，获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法。值得一提的是，内置锁相当于一种互斥锁，意味着最多只有一个线程能持有这种锁。要注意了，任何一个执行同步代码块的线程，都不能看到有其他线程正在执行由同一锁保护的同步代码块（这里涉及到可见性的问题）。synchronized直接加在方法上，虽然能很方便的解决线程安全的问题，但是也会带来性能低下的问题，所以synchronized怎么使用，也是值得学习的。
 
可重入函数可以由多于一个任务并发使用，而不必担心数据错误。相反，不可重入函数不能由超过一个任务所共享，除非能确保函数的互斥（或者使用信号量，或者在代码的关键部分禁用中断）。可重入函数可以在任意时刻被中断，稍后再继续运行，不会丢失数据。可重入函数要么使用本地变量，要么在使用全局变量时保护自己的数据。
 
当某个线程请求一个由其他线程持有的锁时，发出请求的线程就会被阻塞，然而，由于内置锁是可重入的，因此如果某个线程试图获得一个已经由它自己持有的锁，那么这个请求就会成功。“重入”意味着获取锁的操作的粒度是线程，而不是调用。重入的一种实现方式是，为每一个锁关联一个获取计数值和一个所有者线程，当计数值为0时，这个锁就被认为是没有被任何线程持有。当线程请求一个未被持有的锁时，JVM将记下锁的持有者，并且将获取计数值置为1，如果同一个线程再次请求获取这个锁，计数值将递增，而当线程退出同步代码块时，计数器会相应的递减，当计数值为0时，这个锁将被释放。
 
到此我们就可以将多个复合操作封装到一个同步代码块中，但是这样是不够的，如果用同步代码块来协调对某个变量的访问，那么在访问这个变量的所有位置上都需要使用同步。而且，当使用锁来协调对某个变量的访问是，在访问变量的所有位置上都要使用同一个锁。而且，并不是只有在写入共享变量时才需要使用同步，对于可能被多个线程同时访问的可变状态变量，在访问它时都需要有同一个锁，这种情况下，我们成状态变量时由这个锁保护的。
 
在这里值得一提的是，当使用锁时，你应该清楚代码块中实现的功能，以及在执行该代码块时是否需要很长的时间。无论是执行计算密集的操作，还是在执行某个可能阻塞的操作，如果持有锁的时间过长，那么都会带来活跃性或性能的问题。当执行时间较长的计算或者可能无法快速完成的操作时（例如网络IO或控制台IO），一定不要持有锁。

原子操作是指一个不受其他操作影响的操作任务单元。原子操作是在多线程环境下避免数据不一致必须的手段。  
  
 
处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。 
  
 
在Java中可以通过锁和循环CAS的方式来实现原子操作。 CAS操作——Compare & Set，或是 Compare & Swap，现在几乎所有的CPU指令都支持CAS的原子操作。
 
int++并不是一个原子操作，所以当一个线程读取它的值并加1时，另外一个线程有可能会读到之前的值，这就会引发错误。 
  
 
为了解决这个问题，必须保证增加操作是原子的，在JDK1.5之前我们可以使用同步技术来做到这一点。到JDK1.5，java.util.concurrent.atomic包提供了int和long类型的原子包装类，它们可以自动的保证对于他们的操作是原子的并且不需要使用同步。
 
java.util.concurrent这个包里面提供了一组原子类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。
  

一个典型的例子是在类中有一个 long 类型的成员变量。如果你知道该成员变量会被多个线程访问，如计数器、价格等，你最好是将其设置为 volatile。为什么？因为 Java 中读取 long 类型变量不是原子的，需要分成两步，如果一个线程正在修改该 long 变量的值，另一个线程可能只能看到该值的一半（前 32 位）。但是对一个 volatile 型的 long 或 double 变量的读写是原子。
 以上是网络上搜索到的答案。
 我觉得是 不能把非源子操作改成源子操作，毕竟存在i++这种操作，而且从本质上来讲 ，volatile只能保证内存可见性，而不是保证原子性，原理可参考https://blog.csdn.net/T_luyang_T/article/details/103188314。
 而且原子性和可见性的含义都是不一样的 ，这个问题从问法上就是有问题。
 
可见性：一个线程对共享变量的修改，更够及时的被其他线程看到
 原子性：即不可再分了，不能分为多步操作。比如赋值或者return。比如"a = 1;"和 "return a;"这样的操作都具有原子性。类似"a += b"这样的操作不具有原子性，在某些JVM中"a += b"可能要经过这样三个步骤：
 ①　取出a和b
 ②　计算a+b
 ③　将计算结果写入内存
 
但是Synchronize是可以保证可见性和原子性
 
最后Synchronized和Volatile的比较
 
1）Synchronized保证内存可见性和操作的原子性
2）Volatile只能保证内存可见性
3）Volatile不需要加锁，比Synchronized更轻量级，并不会阻塞线程（volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。）
4）volatile标记的变量不会被编译器优化,而synchronized标记的变量可以被编译器优化（如编译器重排序的优化）.
5）volatile是变量修饰符，仅能用于变量，而synchronized是一个方法或块的修饰符。
  volatile本质是在告诉JVM当前变量在寄存器中的值是不确定的，使用前，需要先从主存中读取，因此可以实现可见性。而对n=n+1,n++等操作时，volatile关键字将失效，不能起到像synchronized一样的线程同步（原子性）的效果。