乐观锁 & 悲观锁
乐观锁和悲观锁是在数据库中引入的名词，但是在 Java 并发包锁里面也引入了类似的思想。
悲观锁
悲观锁 指对数据被外界修改持保守态度，认为数据很容易就会被其他线程修改，所以在数据被处理前先对数据进行加锁，并在整个数据处理过程中，使数据处于锁定状态。
悲观锁 的实现往往依靠数据库提供的锁机制，即在数据库中，在对数据记录操作前给记录加排它锁。如果获取锁失败，则说明数据正在被其他线程修改，当前线程则等待或者抛出异常。如果获取锁成功，则对记录进行操作，然后提交事务后释放排它锁。
public int updateEntry(long id) l
// 使用悲观锁获取指定记录
EntryObject entry = query("select * from table1 where id=#{id} for update", id) ;
// 修改名称
entry.setName (“new name”) ;
// 执行更新操作
int count = update("update table1 set name=#{name}, age=#{age} where id=#{id}",entry) ;
return count;
}
当多个线程同时调用 updateEntry 方法,并且传递的是同一个id时,只有一个线程执行代码 query 方法会成功，其他线程则会被阻塞,这是因为在同一时间只有一个线程可以获取对应记录的锁，在获取锁的线程释放锁前 ( update Entry执行完毕,提交事务之前 )，其他线程必须等待,也就是在同一时间只有一个线程可以对该记录进行修改。
乐观锁
乐观锁 是相对悲观锁来说的，它认为数据在一般情况下不会造成冲突，所以在访问记录前不会加排它锁，而是在进行数据提交更新时，才会正式对数据冲突与否进行检测。具体来说，根据update返回的行数让用户决定如何去做。将上面的例子改为使用乐观锁的代码如下。
public int updateEntry(long id) {
//(1)使用乐观锁获取指定记录
EntryObject entry = query("select * from table1 where id = #{id}",id) ;
//(2)修改记录内容，version 字段不能被修改
entry.setName(“name”);
// (3) update操作
int count = update("update table1 set name=#{name} , age=#{age}, version=${version}+1 where id =#{id} and version=#{version}",entry);
return count;
}
乐观锁并不会使用数据库提供的锁机制，一般在表中添加version字段或者使用业务状态来实现。乐观锁直到提交时才锁定，所以不会产生任何死锁。
公平锁 & 非公平锁
根据线程获取锁的抢占机制，锁可以分为公平锁和非公平锁，公平锁表示线程获取锁的顺序是按照线程请求锁的时间先后来决定的，也就是最先请求锁的线程将最先获取到锁。而非公平锁则在运行时闯入，也就是先来不一定先得。
例如，假设线程A已经持有了锁，这时候线程B请求该锁其将会被挂起。当线程A释放锁后，假如当前有线程C也需要获取该锁，如果采用非公平锁方式，则根据线程调度策略，线程B和线程C两者之一可能获取锁，这时候不需要任何其他干涉，而如果使用公平锁则需要把C挂起，让B获取当前锁。
在没有公平性需求的前提下尽量使用非公平锁，因为公平锁会带来性能开销
独占锁 & 共享锁
根据锁只能被单个线程持有还是能被多个线程共同持有,锁可以分为独占锁和共享锁。
独占锁保证任何时候都只有一个线程能得到锁，ReentrantLock 就是以独占方式实现的。共享锁则可以同时由多个线程持有，例如 ReadWriteLock 读写锁，它允许一个资源可以被多线程同时进行读操作。
独占锁是一种悲观锁，由于每次访问资源都先加上互斥锁，这限制了并发性，因为读操作并不会影响数据的一致性，而独占锁只允许在同一时间由一个线程读取数据，其他线程必须等待当前线程释放锁才能进行读取。
共享锁则是一种乐观锁，它放宽了加锁的条件，允许多个线程同时进行读操作。
可重入锁
当一个线程要获取一个被其他线程持有的独占锁时，该线程会被阻塞，那么当一个线程再次获取它自己已经获取的锁时是否会被阻塞呢?如果不被阻塞，那么我们说该锁是可重入的，也就是只要该线程获取了该锁，那么可以无限次数(严格来说是有限次数)地进入被该锁锁住的代码。
synchronized 内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程
标示，用来标示该锁目前被哪个线程占用，然后关联一个计数器。一开始计数器值为 0，说明该锁没有被任何线程占用。当一个线程获取了该锁时,计数器的值会变成1,这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。
但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己，就会把计数器值加+1，当释放锁后计数器值-1。当计数器值为0时，锁里面的线程标示被重置为null，这时候被阻塞的线程会被唤醒来竞争获取该锁。
自旋锁
由于Java中的线程是与操作系统中的线程一一对应的，所以当一个线程在获取锁(比如独占锁)失败后，会被切换到内核状态而被挂起。当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。而从用户状态切换到内核状态的开销是比较大的，在一定程度上会影响并发性能。自旋锁则是，当前线程在获取锁时，如果发现锁已经被其他线程占有，它不马上阻塞自己，在不放弃CPU使用权的情况下，多次尝试获取(默认次数是10，可以使用 -XX:PreBlockSpinsh 参数设置该值)，很有可能在后面几次尝试中其他线程已经释放了锁。如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销，但是很有可能这些CPU时间白白浪费了。
Lock 接口
在 Lock 接口出现之前，Java 程序是靠 synchronized 关键字实现锁功能的，而 Java Se5 之后，并发包中新增了 Lock 接口(以及相关实现类)用来实现锁功能，它提供了与 synchronized 关键字类似的同步功能,只是在使用时需要显式地获取和释放锁。虽然它缺少了(通过 synchronized 块或者方法所提供的)隐式获取释放锁的便捷性,但是却拥有了锁获取与释放的可操作性、可中断的获取锁以及超时获取锁等多种 synchronized 关键字所不具备的同步
特性。
使用 synchronized 关键字将会隐式地获取锁，但是它将锁的获取和释放固化了，也就是先获取再释放。当然,这种方式简化了同步的管理，可是扩展性没有显示的锁获取和释放来的好。Lock 的使用其实也很简单，如下代码
Lock lock = new ReentrantLock();
lock.lock();
try{
}finally{
lock.unlock();
}
在 finally 块中释放锁，目的是保证在获取到锁之后，最终能够被释放。
Lock 接口方法
void lock()；
获取锁,调用该方法当前线程将会获取锁,当锁获得后,从该方法返回void lockInterruptibly() throws InterruptedException；
可中断地获取锁，和 lock 方法的不同之处在于该方法会响应中断，即在锁的获取中可以中断当前线程boolean tryLock()
尝试非阻塞的获取锁,调用该方法后立刻返回，如果能够获取则返回 true，否则返回 false-
boolean tryLock(long time, TimeUnit unit) throws InterruptedException；
超时的获取锁,当前线程在以下3种情况下会返回:- 当前线程在超时时间内获得了锁
- 当前线程在超时间内被中断
- 超时时间结束,返回 false
void unlock
释放锁Condition newCondition()；
获取等待通知组件，该组件和当前的锁绑定，当前线程只有获得了锁，才能调用该组件的 wait 方法，而调用后，当前线程将释放锁