- 并发需要同步解决的问题:
原子性:
多个线程的操作要么全部成功,要么全部不成功;
可见性:
单个线程的修改,对其他线程的可见性;
有序性:
多个线程的执行顺序应根据执行逻辑有序进行;
- java同步机制
voliate关键字:
被该关键字修饰的变量,在多线程访问时,会立即从线程缓存刷新到工作内存中,且其他线程所读取的缓存也会变得无效;所以能够保证可见性
在执行被该关键字修饰的变量时,会禁止多线程之间的指令排序,保证该指令前的其他线程的所有操作完成(完成线程内存与工作内存的同步),形成内存屏障,所以能够保证一定的有序性;
java内存模型
Java内存模型规定所有的变量都是存在主存当中(类似于前面说的物理内存),每个线程都有自己的工作内存(类似于前面的高速缓存)。线程对变量的所有操作都必须在工作内存中进行,而不能直接对主存进行操作。并且每个线程不能访问其他线程的工作内存。主存其实就是我们经常说的堆区,工作内存就是栈内存;
指令重排序:
处理器为了提高程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。单线程中指令排序不会影响执行结果,但是多线程访问时,指令重排序就会导致执行结果的正确性;而voliate关键字在多线程环境下,会使用lock形成内存屏障,使之前的代码全部执行完毕,之后的命令未开始执行;
由此可见,voliate关键字只能保证并发环境下的可见性和一定的有序性,不能保证原子性和彻底的有序性,但是其轻量的同步成本,使其可以使用在一些不需要根据同步变量连变化的同步场景中;例如线程之间状态的切换操作等;如果基础变量需要保持高度同步,可以考虑使用java.util.concurrent.atomic包下提供了一些原子操作类
Atomic原子类
一般来讲解决线程获取同步锁的机制分为以下两种:
- 等待唤醒机制:
抢不到锁,就将线程挂起,当锁释放时,唤醒线程重新抢锁;适用于等待锁的时间比较长,需要切换线程的状态;
- 自旋CAS
循环CAS获取锁,获取成功则退出;等待锁的时间比较短,自旋期间一直占用CPU;Atomic使用的就是自旋CAS来保证线程安全的;
Synchronized 关键字
Synchronized 实际上是作用在对象的头上,这与对象的内存分布有关:
- 并发需要同步解决的问题:
原子性:
多个线程的操作要么全部成功,要么全部不成功;
可见性:
单个线程的修改,对其他线程的可见性;
有序性:
多个线程的执行顺序应根据执行逻辑有序进行;
- java同步机制
voliate关键字:
被该关键字修饰的变量,在多线程访问时,会立即从线程缓存刷新到工作内存中,且其他线程所读取的缓存也会变得无效;所以能够保证可见性
在执行被该关键字修饰的变量时,会禁止多线程之间的指令排序,保证该指令前的其他线程的所有操作完成(完成线程内存与工作内存的同步),形成内存屏障,所以能够保证一定的有序性;
java内存模型
Java内存模型规定所有的变量都是存在主存当中(类似于前面说的物理内存),每个线程都有自己的工作内存(类似于前面的高速缓存)。线程对变量的所有操作都必须在工作内存中进行,而不能直接对主存进行操作。并且每个线程不能访问其他线程的工作内存。主存其实就是我们经常说的堆区,工作内存就是栈内存;
指令重排序:
处理器为了提高程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的。单线程中指令排序不会影响执行结果,但是多线程访问时,指令重排序就会导致执行结果的正确性;而voliate关键字在多线程环境下,会使用lock形成内存屏障,使之前的代码全部执行完毕,之后的命令未开始执行;
由此可见,voliate关键字只能保证并发环境下的可见性和一定的有序性,不能保证原子性和彻底的有序性,但是其轻量的同步成本,使其可以使用在一些不需要根据同步变量连变化的同步场景中;例如线程之间状态的切换操作等;如果基础变量需要保持高度同步,可以考虑使用java.util.concurrent.atomic包下提供了一些原子操作类
Atomic原子类
一般来讲解决线程获取同步锁的机制分为以下两种:
- 等待唤醒机制:
抢不到锁,就将线程挂起,当锁释放时,唤醒线程重新抢锁;适用于等待锁的时间比较长,需要切换线程的状态;
- 自旋CAS
循环CAS获取锁,获取成功则退出;等待锁的时间比较短,自旋期间一直占用CPU;Atomic使用的就是自旋CAS来保证线程安全的;
Synchronized 关键字
Synchronized 实际上是作用在对象的头上,这与对象的内存分布有关:
如上图所示,synchronized作用的锁就死在对象头的mark word字段中的锁标识状态
当线程进入synchronized 修饰的同步代码块时,同步对象的对象头的mark word字段的锁标识就会被设置为01,同时线程会在自己的线程栈中创建”锁记录(Lock Record)”的空间,用于存储mark word的锁拷贝信息;
Lock record是线程的私有数据结构,每个锁对象mark word 都会和一个线程的lock record关联;lock record 中有一个owner字段,用于存储锁的monitor record,当该线程持有对象锁时,设置为该对象的monitor record,释放锁,则设置为null;
任何一个对象都有一个 Monitor 与之关联,当且一个 Monitor 被持有后,它将处于锁定状态。Synchronized 在 JVM 里的实现都是基于进入和退出 Monitor 对象来实现方法同步和代码块同步,虽然具体实现细节不一样,但是都可以通过成对的 MonitorEnter 和 MonitorExit 指令来实现。
monitor 的作用
monitor 的作用就是限制同一时刻,只有一个线程能进入 monitor 框定的临界区,达到线程互斥,保护临界区中临界资源的安全,这称为线程同步使得程序线程安全。同时作为同步工具,它也提供了管理进程,线程状态的机制,比如 monitor 能管理因为线程竞争未能第一时间进入临界区的其他线程,并提供适时唤醒的功能。
monitor 的组成
1)monitor 对象
monitor 对象是 monitor 机制的核心,它本质上是 jvm 用 c 语言定义的一个数据类型。对应的数据结构保存了线程同步所需的信息,比如保存了被阻塞的线程的列表,还维护了一个基于mutex的锁,monitor 的线程互斥就是通过 mutex 互斥锁实现的。
2)临界区
临界区是被 synchronized 包裹的代码块,可能是个代码块,也可能是个方法。
3)条件变量
条件变量和下方 wait signal 方法的使用有密切关系 。在获取锁进入临界区之后,如果发现条件变量不满足,使用 wait 方法使线程阻塞,条件变量满足后 signal 唤醒被阻塞线程。
tips:当线程被 signal 唤醒之后,不是从 wait 那继续执行的,而是重新 while 循环一次判断条件是否成立。
4)定义在 monitor 对象上的 wait() signal() signalAll() 操作
Synchronized 是什么类型的锁:
悲观锁
非公平锁
可重入锁
排它锁
Synchronized 四中用法:
(1)修饰一个代码块: 一个线程正在访问一个对象中的 synchronized(this 或 其他对象) 同步代码块时,其他试图访问该对象(要是同一个对象)的线程将被阻塞。
(2)修饰一个普通方法: 在方法的前面加 synchronized,public synchronized void method(),此方法等于修饰整个方法代码块。
(3)修饰一个静态的方法:public synchronized static void method(),静态方法是属于类的,同样的,synchronized 修饰的静态方法锁定的是这个类的所有对象。
(4)修饰一个类:synchronized(ClassName.class),synchronized 作用于一个类时,是给这个类加锁,该类的所有对象都将加同一把锁。
public synchronized void staticA(){
}
相当于:
public void run(){
synchronized(this){
...
}
}
使用的是对象锁
public static synchronized void staticA(){
}
相当于
public void run(){
synchronized(Test.Class){
...
}
}
使用的是类锁
synchronized加锁的工作过程
synchronized分为 无锁,偏向锁,轻量级锁,重量级锁的状态,会根据实际情况进行升级膨胀;
- 偏向锁
当只有一个线程多次重复抢占锁同一资源时,即使是轻量级锁每次也至少需要两次(加锁、解锁)CAS操作,为了减少不必要的资源浪费,偏向锁应运而生
只有在第一次进来时,使用CAS将线程ID设置到对象的Mark Word头设置偏向线程ID;以后该线程再次进来时,如果线程ID和设置的偏向线程ID相同,则无需再次使用CAS来加锁、解锁;当遇到其他线程尝试竞争偏向锁时,持有的偏向锁才会释放锁。
偏向锁在 JDK 6 及之后版本的 JVM 里是默认启用的。可以通过 JVM 参数关闭偏向锁:-XX:-UseBiasedLocking=false,关闭之后程序默认会进入轻量级锁状态。
- 轻量级锁
轻量级锁是指当锁是偏向锁的时候,却被另外的线程所访问,此时偏向锁就会升级为轻量级锁,其他线程会通过自旋的形式尝试获取锁,线程不会阻塞,从而提高性能。
轻量级锁的获取主要由两种情况:
① 当关闭偏向锁功能时;
② 由于多个线程竞争偏向锁导致偏向锁升级为轻量级锁。
轻量级锁的锁膨胀
1)若当前只有一个等待线程,则该线程将通过自旋进行等待。但是当自旋超过一定的次数时,轻量级锁便会升级为重量级锁(锁膨胀)。
2)若当一个线程已持有锁,另一个线程在自旋,而此时又有第三个线程来访时,轻量级锁也会升级为重量级锁(锁膨胀)。
3)重量级锁
重量级锁是指当有一个线程获取锁之后,其余所有等待获取该锁的线程都会处于阻塞状态。
重量级锁通过对象内部的监视器(monitor)实现,而其中 monitor 的本质是依赖于底层操作系统的 Mutex Lock 实现,操作系统实现线程之间的切换需要从用户态切换到内核态,切换成本非常高。
简言之,就是所有的控制权都交给了操作系统,由操作系统来负责线程间的调度和线程的状态变更。而这样会出现频繁地对线程运行状态的切换,线程的挂起和唤醒,从而消耗大量的系统资源,导致性能低下。
(1)偏向锁通过对比 Mark Word 解决加锁问题,避免执行 CAS 操作。
(2)轻量级锁是通过用 CAS 操作和自旋来解决加锁问题,避免线程阻塞和唤醒而影响性能。
(3)重量级锁是将除了拥有锁的线程以外的线程都阻塞。
关于synchronized 的优化:
- 锁消除
能不加锁,就不加锁
- 锁粗化
论理来说,锁的同步块越小越好,但是在连续的代码块如果出现多个代码同步块,就需要频繁的加锁解锁,导致性能提升。
锁粗化就是将多个连续的锁合并成一个更大范围的锁,避免频繁的加锁、解锁操作。
ReentrantLock 关键字
Reentrantlock 是实现Lock接口,使用时 通过手动lock()、tryLock()获取锁,本身默认是非公平锁,但可以通过参数设置为公平锁;
那么Reentrantlock 是怎么实现线程阻塞同步的呢?这就与下面提到的AQS(AbstractQueueSynchronizer)息息相关
AQS 内部维护的使一个FIFO的双向链表,当线程抢占锁失败后,会封装成一个Node直接放入AQS阻塞队列中
如上图所示 lock()方法 首先通过自旋CAS方法compareAndSetState来获取锁
CAS操作是通过Unsafe 的compareAndSwapInt方法实现的;
如果自旋失败,则封装为Node直接放入AQS队列中
ReentrantReadWriteLock
ReentrantReadWriteLock实现了ReadWriteLock接口,其中有两把锁,一个ReadLock,一个WriteLock,它们分别实现了Lock接口。适合读多写少的场景。 基本原则:
- 读和读不互斥;
- 读和写互斥;
- 写和写互斥
可中断的lockInterruptibly
获取可中断锁,即在持有锁的过程中,可以被中断,抛出InterruptedException
ReentrantLock 的用法:
Lock()
当前线程获取锁,如果当前锁被其他线程阻塞,直到获取锁。如果锁得不到有效释放,则可能导致程序无法执行下去;
TryLock()
不带参数,表示当前线程尝试获取锁,返回true,表示获取成功,false表示获取失败;
TryLock(long timeout, TimeUnit unit)
表示在指定时间内获取锁,成功则返回true,失败则返回false。在阻塞等待锁期间,支持interruptibly中断;
lockInterruptibly()
等待期间可以响应中断信号,能够避免长时间等待
与synchronized 比较
使用
synchronized是Java关键字,而ReentrantLock是类
加锁方式
synchronized加的是对象锁,是锁膨胀的一个过程,锁膨胀不可逆
ReentrantLock是通过方法加锁,底层是CAS+AQS
公平锁
ReentrantLock可以指定公平锁,默认非公平。
synchronized是非公平锁
响应
ReentrantLock可以尝试加锁,获不获得锁都会继续执行,且可以指定等待获取锁的时间。还可以指定对Interrupter做出相应
synchronized必须拿到锁才能执行,而且synchronized无法指定锁的获取时间
释放
ReentrantLock必须手动释放锁
synchronized会自动释放锁
AbstractQueuedSynchronizer 学习:
https://blog.csdn.net/qq_33479841/article/details/126862201
锁优化
减少锁持有时间
只用在有线程安全要求的程序上加锁
减小锁粒度
将大对象(这个对象可能会被很多线程访问),拆成小对象,大大增加并行度,降低锁竞争。
降低了锁的竞争,偏向锁,轻量级锁成功率才会提高。最最典型的减小锁粒度的案例就是
ConcurrentHashMap。
锁分离
最常见的锁分离就是读写锁 ReadWriteLock,根据功能进行分离成读锁和写锁,这样读读不互斥,读写互斥,写写互斥,即保证了线程安全,又提高了性能。JDK 并发包 1。读写分离思想可以延伸,只要操作互不影响,锁就可以分离。比如LinkedBlockingQueue 从头部取出,从尾部放数据。
锁粗化
通常情况下,为了保证多线程间的有效并发,会要求每个线程持有锁的时间尽量短,即在使用完公共资源后,应该立即释放锁。但是,凡事都有一个度,如果对同一个锁不停的进行请求、同步和释放,其本身也会消耗系统宝贵的资源,反而不利于性能的优化 。
锁消除
锁消除是在编译器级别的事情。在即时编译器时,如果发现不可能被共享的对象,则可以消除这些对象的锁操作,多数是因为程序员编码不规范引起。
多线程协调同步方法:
Synchronized 同步 wait() notify() notifyAll()
Wait() 当前线程释放锁,并等待其他线程唤醒,唤醒后重新竞争获取锁;
notify() 当前线程释放锁,并随机唤醒一个处于等待线程;
notifyAll()当前线程释放锁,并唤醒所有处于等待的线程;但是只有一个线程能够获取锁;具体谁能获取锁是随机的;具体使用代码如下:
public static void main(String[] args) throws InterruptedException {
AjaxResult lock = new AjaxResult();
Thread thread1 = new Thread(() -> {
try {
test1(lock);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
Thread thread2 = new Thread(() -> {
try {
test2(lock);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
Thread thread3 = new Thread(() -> {
try {
test3(lock);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
thread1.start();
thread2.start();
thread3.start();
}
public static void test1(AjaxResult ajaxResult) throws InterruptedException {
synchronized (ajaxResult){
System.out.println("this is method test1 before");
//此时当前线程释放对象ajaxResult锁,并进入等待其他线程执行ajaxResult.notify()方法唤醒,唤醒后重新竞争获取对象ajaxResult锁
sep+=1;
ajaxResult.wait();
System.out.println("this is method test1 end");
ajaxResult.wait();
}
}
public static void test2(AjaxResult ajaxResult) throws InterruptedException {
synchronized (ajaxResult){
System.out.println("this is method test2 before");
//此时当前线程释放对象ajaxResult锁,并进入等待其他线程执行ajaxResult.notify()方法唤醒,唤醒后重新竞争获取对象ajaxResult锁
sep+=1;
ajaxResult.wait();
System.out.println("this is method test2 end");
}
}
public static void test3(AjaxResult ajaxResult) throws InterruptedException {
synchronized (ajaxResult){
System.out.println("this is method test3 before");
//此时当前线程释放obj锁,随机唤醒一个处于等待状态的线程,继续执行wait后面的程序。
//notify()是唤醒单个线程,而notifyAll()是唤醒所有的线程的wait(),但是只有一个线程能够获取到锁;
ajaxResult.notifyAll();
System.out.println("this is method test3 end");
}
}
如上所示 notify 唤醒是随机的,无法精确调用某个线程,当有类似需求时可以使用
ReentrantLock的Condition
ReentrantLock reentrantLock = new ReentrantLock();
Condition condition1 = reentrantLock.newCondition();
Condition condition2 = reentrantLock.newCondition();
代码入下图所示:
public static void main(String[] args) throws InterruptedException {
ReentrantLock reentrantLock = new ReentrantLock();
Condition condition1 = reentrantLock.newCondition();
Condition condition2 = reentrantLock.newCondition();
Thread thread1 = new Thread(() -> {
try {
con1(reentrantLock,condition1);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
Thread thread2 = new Thread(() -> {
try {
con2(reentrantLock,condition2);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
Thread thread3 = new Thread(() -> {
try {
con3(reentrantLock,condition2);
} catch (InterruptedException e) {
e.printStackTrace();
}
});
thread1.start();
thread2.start();
thread3.start();
}
public static void con1(ReentrantLock lock, Condition condition) throws InterruptedException {
lock.lock();
System.out.println("this is method con1 before");
//当前线程释放lock锁,进入等待状态,等待其他线程执行condition.signal()时唤醒
condition.await();
System.out.println("this is method con1 end");
lock.unlock();
}
public static void con2(ReentrantLock lock, Condition condition) throws InterruptedException {
lock.lock();
System.out.println("this is method con2 before");
//当前线程释放lock锁,进入等待状态,等待其他线程执行condition.signal()时唤醒
condition.await();
System.out.println("this is method con2 end");
lock.unlock();
}
public static void con3(ReentrantLock lock, Condition condition) throws InterruptedException {
lock.lock();
System.out.println("this is method con3 before");
//当前线程释放lock锁,执行condition.signal() 唤醒其处于等待状态的线程,继续执行
condition.signal();
System.out.println("this is method con3 end");
lock.unlock();
}
以上便是object对象锁的wait() notify() 与ReentrantLock 锁的condition await() signal()的区别;当需要精确唤醒某个等待线程,使用ReentrantLock锁,否则使用对象锁;
ReentrantLock 的可重入锁是通过设置AbstractOwnableSynchronizer 的state累加来实现的,初始获取锁成功后,值为1;
CountDownLatch 使用
CountDownLatch 可以使当前线程阻塞,等待其他线程完成给定任务时,再解除阻塞;其内部也是使用AQS来实现的;
CountDownLatch的构造函数接受一个int类型作为计数器,如果想等待N个线程完成任务,这里就传N;
CountDownLatch方法:
await() 阻塞当前线程,直到计数器为零为止;
await(long timeout,TimeUnit unit) await()的重载方法,可以指定阻塞时长;
countDown() 计数器减1,如果计数达到零,释放所有等待的线程;
getCount() 返回当前计数;
使用代码如下:
CountDownLatch countDownLatch = new CountDownLatch(5);
ExecutorService executorService = Executors.newFixedThreadPool(5);
for (int i = 0; i < 3; i++) {
executorService.submit(new Runnable() {
@Override
public void run() {
System.out.println("thread is running");
countDownLatch.countDown();
}
});
}
boolean await = countDownLatch.await(20, TimeUnit.SECONDS);
if (await) {
System.out.println("thread already finished");
} else {
System.out.println("thread is gone");
}
executorService.shutdownNow();
CountDownLatch 通常用于主线程等待其他线程执行完毕后,再执行主线程任务的场景
Semaphore 使用
Semaphore是一种并发编程中常用的同步机制,可以用于限制同时访问某个线程资源的线程数量,或者在多个线程之间协调顺序;
构造方法Semaphore(int permits) permits 表示当前有多少个线程可以同时访问Semaphore控制的资源,如果为0,则所有线程都会被阻塞;
Semaphore(int permits, boolean fair) boolean类型的参数fair,表示Semaphore对象是否是公平的。如果fair为true,表示Semaphore对象是公平的,即等待时间最长的线程会优先获取许可;如果fair为false,表示Semaphore对象是非公平的,线程获取许可的顺序是不确定的
acquire() 表示获取一个控制资源许可;
tryAcquire(long timeout,TimeUnit unit) 在指定时间内获取控制资源许可,成功则返回true,失败则返回false;
release() 释放一个控制资源许可,释放后,则可以被其他阻塞线程使用;
availablePermits() 获取Semaphore对象当前可用的许可数量;
代码示例
Semaphore semaphore = new Semaphore(3);
ExecutorService executorService = Executors.newFixedThreadPool(10);
for (int i = 0; i <10 ; i++) {
final int j= i;
executorService.submit(()->{
try {
semaphore.acquire();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("thread is running"+j);
semaphore.release();
});
}
Semaphore使用场景:
1)数据库连接池,同时进行联机的线程有数量限制,不能超过一定的数量;
2)停车场场景,车位数量有限,同时只能容纳多少台车,车位满后只能等里面的车离开才能进入;
3)实现生产者消费者模式,可以控制生产者消费者的并发数量,可以保证数据的安全有效处理;
CyclicBarrier (ˈsaɪkl bɑːrɪə)循环屏障
用于线程协作,让一个线程到达一个屏障时阻塞,直到最后一个线程到达线程时,会触发自己运行;
API介绍
构造方法:
CyclicBarrier(int parties) :创建parties个线程任务的循环CyclicBarrier
CyclicBarrier(int parties,Runnable barrierAction) 当parties个线程到屏障时,自己执行barrierAction
常用API:
Int await() 线程调用await方法通知CyclicBarrier本线程已到达屏障
使用示例如下:
ExecutorService executorService = Executors.newFixedThreadPool(5);
CyclicBarrier cyclicBarrier = new CyclicBarrier(5, () -> {
System.out.println("都到齐了,追奔进入下一阶段。。。。");
});
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 5; j++) {
int x = j;
executorService.submit(() -> {
System.out.println("第" + x + "个开始执行了");
try {
//随机休息几秒,模拟执行时间
Thread.sleep(new Random().nextInt(5000));
System.out.println("第" + x + "个线程到达了");
//获取屏障锁,等待全部到达后才能放行
cyclicBarrier.await();
} catch (InterruptedException e) {
e.printStackTrace();
} catch (BrokenBarrierException e) {
e.printStackTrace();
}
});
}
}
executorService.shutdown();
实现原理:
底层是使用ReentranLock 和其condition唤醒功能实现的;
成员属性
全局锁:利用可重入锁实现的工具类
// barrier 实现是依赖于Condition条件队列,condition 条件队列必须依赖lock才能使用
private final ReentrantLock lock = new ReentrantLock();
// 线程挂起实现使用的 condition 队列,当前代所有线程到位,这个条件队列内的线程才会被唤醒
private final Condition trip = lock.newCondition();
线程数量:
// 代表多少个线程到达屏障开始触发线程任务
private final int parties;
// 表示当前“代”还有多少个线程未到位,初始值为 parties
private int count;
AQS总结:
AQS(AbstractQueuedSynchronizer) 是多线程同步器,提供了两种锁机制:
排它锁:同一时刻,只允许一个线程去访问该共享资源,典型的实现是ReentrantLock可重入锁;
共享锁:也称之为读锁,同一时刻允许多个线程获取锁的资源,比如CountDownLatch、Semaphore。
java中的使用
ReentrantLock
Semsphore
CountDownLatch
ReentrantReadWriteLock
ThreadPoolExecutor
实现机制:
每个Node包含如下属性:waitStatus、prev、next、thread、nextWaiter
几个重要的属性及方法:
State 使用volatile修饰,用于表示竞争资源,共享时可以使用累加
compareAndSetState CAS方式获取锁;
setExclusiveOwnerThread(Thread thread) 设置参数线程thread为锁的独占访问权,当参数为null时,表示释放锁;
继承AbstractQueuedSynchronizer并需要重写的方法
isHeldExclusively()//该线程是否正在独占资源。只有用到condition才需要去实现它。
tryAcquire(int)//独占方式。尝试获取资源,成功则返回true,失败则返回false。
tryRelease(int)//独占方式。尝试释放资源,成功则返回true,失败则返回false。
tryAcquireShared(int)//共享方式。尝试获取资源。负数表示失败;0表示成功,但没有剩余可用资源;正数表示成功,且有剩余资源。
tryReleaseShared(int)//共享方式。尝试释放资源,成功则返回true,失败则返回false。