Java多线程-线程同步（对象锁）

       Java线程同步是用来解决线程间共享资源的。在传统的单线程程序中，程序都是有序的按照程序猿写好的指定的流程运行的，因此对于一些资源，比如某个变量的内存读写顺序是固定的，因此不会出现问题。

       但是在多线程环境下，线程执行时并无规律可言，所以对于资源共享时很容易带来共享的混乱，这是支持并发的OS都面临的问题也就是资源争夺。尤其是真正的多核多线程机器上，多线程的情况更为复杂。资源争夺要做到尽可能多的利用CPU时间，尽可能多的利用资源，减少加锁、解锁带来的额外耗费，避免出现死锁还要再某些情况下共享一些资源。

       Java多线程资源争夺、同步一直是程序猿研究关心的重点，尤其是死锁、同步粒度，这些问题很难预测和重现。而且这部分资料一直很混乱，并没有官方的系统的深入浅出的相关资料，很多都是程序猿从实际“教训”中总结的。

1.基础Synchronized

       单从语法的角度看，要实现线程的同步，或者是解决共享资源的竞争问题很简单，就是在冲突发生时，当资源被一个任务（Thread）使用时，在其上加上锁即可。这个加锁有JVM完成，不需要我们关心，使用Synchronized表示要对这个资源加上锁。就实际开发来说，这个“资源”是我们的方法或者方法内的一块儿代码。

       Synchronized使用的是互斥量机制实现的资源加锁，基本上所有的并发模式在解决线程冲突问题的时候，都是采用的序列化共享资源的方案。这意味着在戈丁时刻只允许一个任务访问共享资源。通常这都是在代码前加上一条锁语句来实现的，这就使得在一段时间内只有一个任务可以运行这段代码。

       或者换个角度，从OS角度看，我们的线程竞争的是对同一块而内存的读写操作，也就是内存资源。而这块儿内存资源在Java中被表现为一个变量、一个对象。当然共享的资源也可以是文件、I/O、打印机等。所有要控制共享资源，得先把它包装进一个对象，然后把所有要访问这个资源的方法标记为Synchronized。而这个对象将被JVM自动赋予一把锁，这就是对象锁。

 

2.对象锁和类锁

       关于Java的对象锁，我一直在寻找一个权威的概念和解释。但是由于资料匮乏，只能从众多Blog、论坛、文档中摘取总结，还有很多不明之处，难以到位。而且在越研究越会发现，需要深入的知识很多。

在JVM的规范中，有这么一些话：（JVM文档原文没有找到）

       （1）  在JVM中，每个对象和类在逻辑上都是和一个监视器相关联的；

       （2）  为了实现监视器的排他性监视能力，JVM为每一个对象和类都关联一个锁；

       （3）  锁住了一个对象，就是获得对象相关联的监视器。

       从这些话，看出监视器和对象锁好像是一回事，那为何要定义两个东西，我本身是想弄明白这两者的区别的，奈何水平有限，只能不求甚解，认为二者是一个东西，或者说JVM的对象监视器就是锁的具体实现。

       JVM的规范中提到每个类和对象都有一个锁，对象锁好理解，当不同线程操作同一个对象时，对于加锁的方法和代码块儿，都需要获取对这个对象的锁。而且对象锁是一个计数器，一个Thread可以对一个对象进行多次加锁（前提是它获取这个对象的锁），这所以允许这么做，是因为在同一个Thread中，程序的执行流程是固定的，对同一个对象在一个Thread多次调用竞争资源是没问题的。

 

对象锁

       所以从对象锁的角度看，一个类的非static方法声明为Synchronized，那么当Thread执行这个方法的时候，会首先获取这个对象的对象锁。那么其他Thread就无法获取这个对象锁了，那么这个对象的所有Synchronized方法都会被锁住。同理，Synchronized块儿需要指定的那个对象，其实就是表明要获得哪个对象的对象锁。用this可以代表当前对象本身。

注意：在并发时，将域（字段）设置为private是非常重要的，否则Synchronized就不能防止其他Thread直接访问该域。

 

类锁

       对于被标记为Synchronized的static method和static块儿，由于一个class不论被实例化多少次，其中的静态方法和静态变量在内存中都只由一份。所以，一旦一个静态的方法被声明为synchronized。此类所有的实例化对象在调用此方法时，共用同一把锁，称之为类锁。一旦一个静态方法被作为synchronized的方法，Thread调用此方法后，都要先获得此静态方法的类锁。

       其实类锁是一个引申概念，系统中实际上并不存在什么类锁。当一个同步静态方法被调用时，系统获取的其实就是代表该类的类对象的对象锁。

3.JDK 1.5的新锁Lock

       JDK 1.5提供了新的加锁方式，Lock类。Lock本身是一个接口，我们需要显示地创建、锁定和释放。因此，它比内建锁代码更繁琐，而且需要配合try-finally块儿调用。

   Lock lock = new ReentrantLock();

    lock.lock();

        try {

            // do something

        }finally{

            lock.unlock();

     }

 

与Synchronized的区别

       Lock的锁定是通过代码实现的，而synchronized 是在 JVM 层面上实现的。

       synchronized 在锁定时如果方法块抛出异常，JVM 会自动将锁释放掉，不会因为出了异常没有释放锁造成线程死锁。但是Lock的话就享受不到JVM带来自动功能，出现异常时必须在 finally 将锁释放掉，否则将会引起死锁。

       在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好，不管用没用过5.0多线程包的程序员都能理解。

       ReentrantLock是Lock接口的一种实现，提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）等。在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍，而ReentrantLock确还能维持常态。