标签：img logs alt 分享 cto 开始 count 分配 value
把代码块声明为 synchronized，有两个重要后果，通常是指该代码具有 原子性（atomicity）和 可见性（visibility）。
volatile的使用条件：
volatile变量具有 synchronized 的可见性特性，但是不具备原子性。这就是说线程能够自动发现 volatile 变量的最新值。
volatile变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。
出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。
使用条件
您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。
第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由（读取－修改－写入）操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果只从单个线程写入，那么可以忽略第一个条件。）
反例
大多数编程情形都会与这两个条件的其中之一冲突，使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全。
【反例：volatile变量不能用于约束条件中】 下面是一个非线程安全的数值范围类。它包含了一个不变式 —— 下界总是小于或等于上界。
public class NumberRange { private volatile int lower; private volatile int upper; public int getLower() { return lower; } public int getUpper() { return upper; } public void setLower(int value) { if (value > upper) throw new IllegalArgumentException(...); lower = value; } public void setUpper(int value) { if (value < lower) throw new IllegalArgumentException(...); upper = value; } }
将 lower 和 upper 字段定义为 volatile 类型不能够充分实现类的线程安全；而仍然需要使用同步——使 setLower()和 setUpper() 操作原子化。
否则，如果凑巧两个线程在同一时间使用不一致的值执行 setLower 和 setUpper 的话，则会使范围处于不一致的状态。例如，如果初始状态是(0, 5)，同一时间内，线程 A 调用setLower(4) 并且线程 B 调用setUpper(3)，显然这两个操作交叉存入的值是不符合条件的，那么两个线程都会通过用于保护不变式的检查，使得最后的范围值是(4, 3) —— 一个无效值。
也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。
volatile boolean shutdownRequested; ... public void shutdown() { shutdownRequested = true; } public void doWork() { while (!shutdownRequested) { // do stuff } }
线程1执行doWork()的过程中，可能有另外的线程2调用了shutdown，所以boolean变量必须是volatile。
而如果使用 synchronized 块编写循环要比使用 volatile 状态标志编写麻烦很多。由于 volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。
这种类型的状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从false 转换为true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从false 到true，再转换到false）。此外，还需要某些原子状态转换机制，例如原子变量。
在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。
这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象。如下面介绍的单例模式。
private volatile static Singleton instace; public static Singleton getInstance(){ //第一次null检查 if(instance == null){ synchronized(Singleton.class) { //1 //第二次null检查 if(instance == null){ //2 instance = new Singleton();//3 } } } return instance; }
安全使用 volatile 的另一种简单模式是：定期 “发布” 观察结果供程序内部使用。【例如】假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。
使用该模式的另一种应用程序就是收集程序的统计信息。
【例】如下代码展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用lastUser 引用来发布值，以供程序的其他部分使用。（主要利用了volatile的可见性）
public class UserManager { public volatile String lastUser; //发布的信息 public boolean authenticate(String user, String password) { boolean valid = passwordIsValid(user, password); if (valid) { User u = new User(); activeUsers.add(u); lastUser = user; } return valid; } }
volatile bean 模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。
在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通——即不包含约束！
public class Person { private volatile String firstName; private volatile String lastName; private volatile int age; public String getFirstName() { return firstName; } public String getLastName() { return lastName; } public int getAge() { return age; } public void setFirstName(String firstName) { this.firstName = firstName; } public void setLastName(String lastName) { this.lastName = lastName; } public void setAge(int age) { this.age = age; } }
如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。
如下显示的线程安全的计数器，使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。
public class CheesyCounter { // Employs the cheap read-write lock trick // All mutative operations MUST be done with the ‘this‘ lock held @GuardedBy("this") private volatile int value; //读操作，没有synchronized，提高性能 public int getValue() { return value; } //写操作，必须synchronized。因为x++不是原子操作 public synchronized int increment() { return value++; } }
使用锁进行所有变化的操作，使用 volatile 进行只读操作。
其中，锁一次只允许一个线程访问值，volatile 允许多个线程执行读操作。
定义：
确保某个类只有一个实例，并提供一个全局访问点。
类图：
public class Singleton{ private static final Singleton instance; private Singleton(){ } public static Singleton getInstance(){ if(instance == null){ //1 instance = new Singleton();//2 } return instance; //3 } ... }
优点：
使用场景：
若出现多个对象就会出现“不良反应”，应该用单例，具体场景如下：
为什么不直接用全局变量来实现单例？
有缺点：全局变量必须在程序一开始就创建好。而单例模式可以延迟初始化。
不同的类加载器可能会加载同一个类。
如果程序有多个类加载器，可在单例中指定某个加载器，并指定同一个加载器。
多线程的影响：
上文代码示例在多线程环境下有bug：
getInstance() 方法并决定 instance 在 //1 处为null。
if 代码块，但在执行 //2 处的代码行时被线程 2 预占。
getInstance() 方法并在 //1 处决定 instance 为 null。
if 代码块并创建一个新的 Singleton 对象并在 //2 处将变量instance 分配给这个新对象。
Singleton 对象引用。
Singleton 对象。
getInstance() 方法创建了两个 Singleton 对象。
解决方法一：不用延迟初始化
public class Singleton{ private static final Singleton instance = new Singleton(); private Singleton(){ } public static Singleton getInstance(){ return instance; } ... }
解决方法二：同步getInstance
public class Singleton{ private static final Singleton instance; private Singleton(){ } //同步getInstance public static synchronized Singleton getInstance(){ if(instance == null){ //1 instance = new Singleton();//2 } return instance; //3 } ... }
但是synchronized方法会降低性能，尤其这里仅当第一次调用getInstance时才需要同步，只有执行//2代码行时才需要同步。
你可能想到只同步方法块，即只对//2进行同步：
public static Singleton getInstance(){ if(instance == null){ synchronized(Singleton.class) { instance = new Singleton(); } } return instance; }
但这样做并不能解决问题：
当 instance 为 null 时，两个线程可以并发地进入if 语句内部。
然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。
当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个Singleton 对象。
注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。
还是会创建2个对象。
解决方法三：双重检查加锁
针对上述方法的缺点，我们在//2代码行时 再检查一次null，就能保证只创建一个对象：
//注意volatile！！ private volatile static Singleton instace; public static Singleton getInstance(){ //第一次null检查 if(instance == null){ synchronized(Singleton.class) { //1 //第二次null检查 if(instance == null){ //2 instance = new Singleton();//3 } } } return instance;
}
假设有下列事件序列：
对于上面解说的赋值，却没有初始化的原因，是由于java变量重新赋值时有3个步骤的（读取，修改，回写）
代码行 instance =new Singleton(); 执行了下列伪代码
1. mem = allocate(); //Allocate memory for Singleton object. 2. instance = mem; //Note that instance is now non-null, but //has not been initialized. 3. ctorSingleton(instance); //Invoke constructor for Singleton passing //instance.
标签：img logs alt 分享 cto 开始 count 分配 value
原文地址：http://www.cnblogs.com/ouyxy/p/7242563.html
