java中的锁

synchronized是在 JVM 层面上实现的，内部实现依次是偏向锁 轻量级锁、重量级锁。在锁定时如果方法块抛出异常，JVM 会自动将锁释放掉，不会因为出了异常没有释放锁造成线程死锁。在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的。原因在于，编译程序通常会尽可能的进行优化synchronize，另外可读性非常好

 

Lock的锁定是通过代码实现的。需要手动释放锁，出现异常时必须在 finally 将锁释放掉，否则将会引起死锁

ReentrantLock与synchrozized区别：

ReentrantLock提供了多样化的同步，比如有时间限制的同步，可以被Interrupt的同步（synchronized的同步是不能Interrupt的）。

在资源竞争不激烈的情形下，性能稍微比synchronized差点点。但是当同步非常激烈的时候，synchronized的性能一下子能下降好几十倍。而ReentrantLock确还能维持常态。 

 

Atomic
和上面的类似，不激烈情况下，性能比synchronized略逊，而激烈的时候，也能维持常态。激烈的时候，Atomic的性能会优于ReentrantLock一倍左右。 

 

1.Lock接口

在Lock接口出现之前，Java程序是靠synchronized关键字实现锁功能的，而Java SE 5之后，并发包中新增了Lock接口（以及相关实现类）用来实现锁功能，它提供了与synchronized关键字类似的同步功能，只是在使用时需要显式地获取和释放锁。虽然它缺少了（通过synchronized块或者方法所提供的）隐式获取释放锁的便捷性，但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种synchronized关键字所不具备的同步特性。使用synchronized关键字将会隐式地获取锁，但是它将锁的获取和释放固化了，也就是先获取再释放。当然，这种方式简化了同步的管理，可是扩展性没有显示的锁获取和释放来的好

2　重入锁

重入锁ReentrantLock，顾名思义，就是支持重进入的锁，它表示该锁能够支持一个线程对资源的重复加锁。除此之外，该锁的还支持获取锁时的公平和非公平性选择。回忆在同步器一节中的示例（Mutex），同时考虑如下场景：当一个线程调用Mutex的lock()方法获取锁之后，如果再次调用lock()方法，则该线程将会被自己所阻塞，原因是Mutex在实现tryAcquire(int acquires)方法时没有考虑占有锁的线程再次获取锁的场景，而在调用tryAcquire(int acquires)方法时返回了false，导致该线程被阻塞。简单地说，Mutex是一个不支持重进入的锁。而synchronized关键字隐式的支持重进入，比如一synchronized修饰的递归方法，在方法执行时，执行线程在获取了锁之后仍能连续多次地获得该锁，而不像Mutex由于获取了锁，而在下一次获取锁时出现阻塞自己的情况。

ReentrantLock虽然没能像synchronized关键字一样支持隐式的重进入，但是在调用lock()方法时，已经获取到锁的线程，能够再次调用lock()方法获取锁而不被阻塞。这里提到一个锁获取的公平性问题，如果在绝对时间上，先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。公平的获取锁，也就是等待时间最长的线程最优先获取锁，也可以说锁获取是顺序的。ReentrantLock提供了一个构造函数，能够控制锁是否是公平的。事实上，公平的锁机制往往没有非公平的效率高，但是，并不是任何场景都是以TPS作为唯一的指标，公平锁能够减少“饥饿”发生的概率，等待越久的请求越是能够得到优先满足。非公平性锁虽然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。因此，非公平性锁是默认机制。

查看源码可知，公平锁机制时jvm要从线程等待队列中获取队列头线程，增加了开销，这就是性能差的主要原因

Lock lock = new ReentrantLock();
lock.lock();
try {
    } 
finally {
    lock.unlock();
}

 

实现重进入

重进入是指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞，该特性的实现需要解决以下两个问题。

1）线程再次获取锁。锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。

2）锁的最终释放。线程重复n次获取了锁，随后在第n次释放该锁后，其他线程能够获取到该锁。锁的最终释放要求锁对于获取进行计数自增，计数表示当前锁被重复获取的次数，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放。

 

 

3.读写锁

之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写锁，使得并发性相比一般的排他锁有了很大提升。一般情况下，读写锁的性能都会比排它锁好，因为大多数场景读是多于写的。在读多于写

的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是ReentrantReadWriteLock，它提供的特性如表5-8所示。

一下示例为 java api并发库中 ReentrantReadWriteLock自带的实例，下面进行解读
 class CachedData {
   Object data;
   volatile boolean cacheValid;
   ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
     rwl.readLock().lock();//@1
     if (!cacheValid) {
        // Must release read lock before acquiring write lock
        rwl.readLock().unlock();//@4
        rwl.writeLock().lock();//@2
        // Recheck state because another thread might have acquired
        //   write lock and changed state before we did.
        if (!cacheValid) {//@3
          data = ...
          cacheValid = true;
        }
        // Downgrade by acquiring read lock before releasing write lock
        rwl.readLock().lock();
        rwl.writeLock().unlock(); // Unlock write, still hold read
     }

     use(data);
     rwl.readLock().unlock();
   }
 }

//当有n多线程 使用同一CachedData 实例对象 调用processCachedData方法时，就会产生线程的并发问题.

@1行，当有线程正在对数据进行 写操作的时候，运行到@1行的线程要等待 写操作的完成，因为第一个运行到@2的线程会加上锁，然后对数据进行需该，期间不允许任何线程进行读或者是写的操作，
当写完后，在该线程上加上读锁操作，以防止解写锁后，别的线程对数据再次进行写时出错.在第一个运行到@2的线程之后的很多线程，
可能已经运行到了@4,当对数据修改好之后，解除掉写锁，别的线程就会执行到@2，这时第一个线程已经经数据修改好了，所以有了@3的判断。
在编写多线程程序的时候,要置于并发线程的环境下考虑，巧妙的运用ReentrantReadWriteLock，在运用时，注意锁的降级，写入锁可以获得读锁，读锁不可以获得写入锁，所以在上写入锁时，必须先将读锁进行解除，然后上读锁。

使用时注意的几个方面：
　　 读锁是排写锁操作的，读锁不排读锁操作，多个读锁可以并发不阻塞。即在读锁获取后和读锁释放之前，写锁并不能被任何线程获得，
　　多个读锁同时作用期间，试图获取写锁的线程都处于等待状态，当最后一个读锁释放后,试图获取写锁的线程才有机会获取写锁。
　　写锁是排写锁、排读锁操作的。当一个线程获取到写锁之后，试图获取写锁和读锁的其他线程都处于等待状态，直到写锁被释放（同一个线程在获取写锁后是可以继续获得读锁的）。即:
　　　　　　rwl.writeLock().lock();
　　　　　　//在写锁状态中，可以获取读锁
　　　　　　rwl.readLock().lock();
　　　　　　rwl.writeLock().unlock();
　　读锁是不能够获得写锁的，如果要加写锁，本线程必须释放所持有的读锁，即:
　　　　　　 rwl.readLock().lock();
　　　　　　//......
　　　　　　//必须释放掉读锁，才能够加写锁
　　　　　　rwl.readLock().unlock();
　　　　　　rwl.writeLock().lock();