java 同步机制

为了解决多线程中的对同一变量的访问冲突。

原子性：具有原子性的操作被称为原子操作。原子操作在操作完毕之前不会线程调度器中断。

可见性：可见性，是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。

java同步机制有4种实现方式：

1.ThreadLocal

2. volatile

3. synchronized

4. wait()与notify()

ThreadLocal

ThreadLocal 保证不同线程拥有不同实例，相同线程一定拥有相同的实例，即为每一个使用该变量的线程提供一个该变量值的副本，每一个线程都可以独立改变自己的副本，而不是与其它线程的副本冲突。

优势：提供了线程安全的共享对象

与其它同步机制的区别：同步机制是为了同步多个线程对相同资源的并发访问，是为了多个线程之间进行通信；而 ThreadLocal 是隔离多个线程的数据共享，从根本上就不在多个线程之间共享资源，这样当然不需要多个线程进行同步了。

使用技巧：需要多个线程之间进行通信：使用同步机制；如果需要隔离多个线程之间的共享冲突：推荐使用 ThreadLocal （线程安全）

volatile

volatile修饰的成员变量在每次被线程访问时，都强迫从共享内存中重读该成员变量的值，而且，当成员变量发现变化时，强迫线程将变化值回写到共享内存。

优势：这样在任何时刻，两个不同的线程总是看到某个成员变量的同一个值。

**缘由：**Java 语言规范中指出：为了获得最佳速度，允许线程保存共享成员变量的私有拷贝，而且只当线程进入或者离开同步代码块时才与共享成员变量的原始值对比。

这样当多个线程同时与某个对象交互时，就必须要注意到要让线程及时的得到共享成员变量的变化。

而 volatile 关键字就是提示 VM ：对于这个成员变量不能保存它的私有拷贝，而应直接与共享成员变量交互。

使用技巧：在两个或者更多的线程访问的成员变量上使用 volatile 。当要访问的变量已在 synchronized 代码块中，或者为常量时，不必使用。

由于使用 volatile 屏蔽掉了 VM 中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

线程为了提高效率，将某成员变量（如A）拷贝了一份（如B），线程中对A的访问其实访问的是B。

只在某些动作时才进行A和B的同步，因此存在A和B不一致的情况。volatile就是用来避免这种情况的。

volatile告诉jvm，它所修饰的变量不保留拷贝，直接访问主内存的（也就是上面说的A）

volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现 volatile 变量的最新值。volatile 变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值;与修改后值之间没有约束。

sleep() vs wait()

sleep是线程类（Thread）的方法，导致此线程暂停执行指定时间，把执行机会给其他线程，但是监控状态依然保持，到时后会自动恢复。调用sleep不会释放对象锁。

wait是Object类的方法，对此对象调用wait方法导致本线程放弃对象锁，进入等待此对象的等待锁定池，只有针对此对象发出notify方法（或notifyAll）后本线程才进入对象锁定池准备获得对象锁进入运行状态。

synchronized

每一个对象本身都隐含着一个锁对象，这个锁对象就是用来解决并发问题的互斥量。要调用一个对象的synchronized方法的线程，必须持有这个对象的锁对象，在执行完毕之后，必须释放这个锁对象，以让别的线程得到这个锁对象。。因为一个对象仅有一个锁对象，这就保证了在同一时刻，最多只有一个线程能够调用并执行这个对象的synchronized方法。其他想调用这个对象的synchronized方法的线程必须等待当前线程释放锁。

在进一步阐述之前，我们需要明确几点：

A．无论synchronized关键字加在方法上还是对象上，他取得的锁都是对象，而不是把一段代码或函数当作锁――而且同步方法很可能还会被其他线程的对象访问。

B．每个对象只有一个锁（lock）和之相关联。

C．实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。

接着来讨论synchronized用到不同地方对代码产生的影响：

假设P1、P2是同一个类的不同对象，这个类中定义了以下几种情况的同步块或同步方法，P1、P2就都能够调用他们。

1． 把synchronized当作函数修饰符时，示例代码如下：

Public synchronized void method(){
//…
}

这也就是同步方法，那这时synchronized锁定的是哪个对象呢？他锁定的是调用这个同步方法对象。也就是说，当一个对象P1在不同的线程中执行这个同步方法时，他们之间会形成互斥，达到同步的效果。但是这个对象所属的Class所产生的另一对象P2却能够任意调用这个被加了synchronized关键字的方法。

上边的示例代码等同于如下代码：

public void method()
{
synchronized (this)      //  (1)
{
//…
}
}

(1)处的this指的是什么呢？他指的就是调用这个方法的对象，如P1。可见同步方法实质是将synchronized作用于object reference。――那个拿到了P1对象锁的线程，才能够调用P1的同步方法，而对P2而言，P1这个锁和他毫不相干，程式也可能在这种情形下摆脱同步机制的控制，造成数据混乱

2．同步块，示例代码如下：

public void method(SomeObject so) {
synchronized(so)
{
//…
}
}

这时，锁就是so这个对象，谁拿到这个锁谁就能够运行他所控制的那段代码。当有一个明确的对象作为锁时，就能够这样写程式，但当没有明确的对象作为锁，只是想让一段代码同步时，能够创建一个特别的instance变量（他得是个对象）来充当锁：

class Foo implements Runnable
{
private byte[] lock = new byte[0];  // 特别的instance变量
Public void method()
{
synchronized(lock) { //… }
}
//…
}

注：零长度的byte数组对象创建起来将比任何对象都经济――查看编译后的字节码：生成零长度的byte[]对象只需3条操作码，而Object lock = new Object()则需要7行操作码。

3．将synchronized作用于static 函数，示例代码如下：

Class Foo
{
public synchronized static void method1()
// 同步的static 函数
{
//…
}
public void method2()
{
synchronized(Foo.class)   // class literal(类名称字面常量)
}
}

代码中的method2()方法是把class literal作为锁的情况，他和同步的static函数产生的效果是相同的，取得的锁很特别，是当前调用这个方法的对象所属的类（Class，而不再是由这个Class产生的某个具体对象了）。

记得在《Effective Java》一书中看到过将 Foo.class和 P1.getClass()用于作同步锁还不相同，不能用P1.getClass()来达到锁这个Class的目的。P1指的是由Foo类产生的对象。

能够推断：假如一个类中定义了一个synchronized的static函数A，也定义了一个synchronized 的instance函数B，那么这个类的同一对象Obj在多线程中分别访问A和B两个方法时，不会构成同步，因为他们的锁都不相同。A方法的锁是Obj所属的那个Class，而B的锁是Obj所属的这个对象。

更有一些技巧能够让我们对共享资源的同步访问更加安全：

1． 定义private 的instance变量+他的 get方法，而不要定义public/protected的instance变量。假如将变量定义为public，对象在外界能够绕过同步方法的控制而直接取得他，并改变他。这也是JavaBean的标准实现方式之一。

2． 假如instance变量是个对象，如数组或ArrayList什么的，那上述方法仍然不安全，因为当外界对象通过get方法拿到这个instance对象的引用后，又将其指向另一个对象，那么这个private变量也就变了，岂不是很危险。 这个时候就需要将get方法也加上synchronized同步，并且，只返回这个private对象的clone()――这样，调用端得到的就是对象副本的引用了。

volatile和synchronized的区别

volatile是变量修饰符，而synchronized则作用于一段代码或方法。

volatile一般情况下不能代替sychronized，因为volatile不能保证操作的原子性，即使只是i++，实际上也是由多个原子操作组成：read i; inc; write i，假如多个线程同时执行i++，volatile只能保证他们操作的i是同一块内存，但依然可能出现写入脏数据的情况。

转载：

http://leo-faith.iteye.com/blog/177779

http://www.blogjava.net/crazycy/archive/2006/10/14/75085.html