标签：exp wap 说明 保存 负数 spl text 有一个 分配
1.为什么要使用锁？
1.1首先说明两个定义：
- 进程：程序启动，进入内存，资源分配的基本单位
- 线程：程序执行的基本单元，程序执行的基本单位
1.2程序如何开始运行？
- Cpu读指令 pc（程序计数器，存储指令地址）
- 读数据 Register
- 计算，回写
- 下一条
1.3多线程带来的问题：
多线程是指一个进程在执行过程中可以产生多个更小的程序单元，这些更小的单元称为线程，这些线程可以同时存在，同时运行，一个进程可能包含多个同时执行的线程。一个进程可以包含多个线程，线程之间通过操作系统（linux线程调度器）来进行调度。
线程切换： Context Switch CPU保存线程，执行新线程，回复线程，继续执行原线程。
多个线程对同一资源同时访问时，如果不加锁，就有可能出现线程安全问题，举例：比如有两张票，但是有5个人进来买，买了一张票数就减1，在他们进门的时候会判断是否还有票，但是在他们进门的那一刻，票还一张都没有买走。但是他们都已经进门了，过了是否有票的校验了，所以最后票数为被减成负3，显然是不对的，因为票不能小于0，所以需要加一个锁，在同一时刻只能有一个人进门去买票，也就是同一个资源同一个时刻只能有一个线程进行操作，这样在第三个人进门的时候就能判断出票数已经卖完了，不会产生票数成负数的情况。
2.synchronized
Java中的关键字，是一种同步锁，锁升级的过程：
偏向锁-->轻量级锁-->重量级锁
3.ReentrantLock
java除了使用关键字synchronized外，还可以使用ReentrantLock实现独占锁的功能。而且ReentrantLock相比synchronized而言功能更加丰富，使用起来更为灵活，也更适合复杂的并发场景。
这两种同步方式有很多相似之处，它们都是加锁方式同步，而且都是阻塞式的同步，
也就是说当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待，而进行线程阻塞和唤醒的代价是比较高的（操作系统需要在用户态与内核态之间来回切换，代价很高，不过可以通过对锁优化进行改善）。
功能区别：
对于Synchronized来说，它是java语言的关键字，是原生语法层面的互斥，需要jvm实现。而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成
便利性：
Synchronized的使用比较方便简洁，并且由编译器去保证锁的加锁和释放，而ReenTrantLock需要手工声明来加锁和释放锁，为了避免忘记手工释放锁造成死锁，所以最好在finally中声明释放锁。
ReenTrantLock独有的能力：
- ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。
- ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。
- ReenTrantLock提供了更多的加锁方式
- lock(), 如果获取了锁立即返回，如果别的线程持有锁，当前线程则一直处于休眠状态，直到获取锁
- tryLock(), 如果获取了锁立即返回true，如果别的线程正持有锁，立即返回false；
- tryLock(long timeout,TimeUnit unit)， 如果获取了锁定立即返回true，如果别的线程正持有锁，会等待参数给定的时间，在等待的过程中，如果获取了锁定，就返回true，如果等待超时，返回false；
- lockInterruptibly:如果获取了锁定立即返回，如果没有获取锁，当前线程处于休眠状态，直到获得锁，或者当前线程被别的线程中断一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。
4.锁的类型
1.可重入锁
如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。
class MyClass {
public synchronized void method1() {
method2();
}
public synchronized void method2() {
}
}
上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。
而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。
2.可中断锁
可中断锁：顾名思义，就是可以相应中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。lockInterruptibly()方法。
3.公平锁
公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。
非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。
在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。
而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。
我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：
ReentrantLock lock = new ReentrantLock(true);
如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。
另外在ReentrantLock类中定义了很多方法，比如：
- isFair()//判断锁是否是公平锁
- isLocked()//判断锁是否被任何线程获取了
- isHeldByCurrentThread()//判断锁是否被当前线程获取了
- hasQueuedThreads()//判断是否有线程在等待该锁,读操作不会发生冲突。
ReadWriteLock是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。可以通过readLock()获取读锁，通过writeLock()获取写锁。
Java锁的认识
标签：exp wap 说明 保存 负数 spl text 有一个 分配
原文地址：https://www.cnblogs.com/jiezai/p/13515273.html
