通过ReentrantLock、状态位来实现
public class ThreadABC2 {
// 锁
private static ReentrantLock lock = new ReentrantLock();
// 状态
private static int state = 0;
// 计数器
private static CountDownLatch countDownLatch = new CountDownLatch(3);
// 线程A
static class ThreadA extends Thread {
@Override
public void run() {
for (int i = 0; i < 3; ) {
try {
lock.lock();
while (state % 3 == 0) {
i++;
state++;
System.out.println("A");
}
}finally {
lock.unlock();
}
}
countDownLatch.countDown();
}
}
// 线程B
static class ThreadB extends Thread {
@Override
public void run() {
for (int i = 0; i < 3; ) {
try {
lock.lock();
while (state % 3 == 1) {
i++;
state++;
System.out.println("B");
}
}finally {
lock.unlock();
}
}
countDownLatch.countDown();
}
}
// 线程C
static class ThreadC extends Thread {
@Override
public void run() {
for (int i = 0; i < 3; ) {
try {
lock.lock();
while (state % 3 == 2) {
i++;
state++;
System.out.println("C");
}
}finally {
lock.unlock();
}
}
countDownLatch.countDown();
}
}
public static void main(String[] args) throws InterruptedException {
long start = System.currentTimeMillis();
new ThreadA().start();
new ThreadB().start();
new ThreadC().start();
countDownLatch.await();
System.out.println("打印耗时:"+(System.currentTimeMillis()-start)+"ms");
}
}
打印结果如下:
但是实际结果真的就是ThreadA先执行,其次ThreadB执行,最后是ThreadC执行吗?恐怕不是吧,毕竟线程的抢占执行并非能人为控制的,因此我们在while条件执行之后添加一条输出,如图:
输出结果:
执行耗时:
可以看到从输出“A”到输出“B”之间输出了n条“ThreadA”,也就说明了,当线程一旦start启动,集体哪个线程能抢占资源成功,无法确定(且与代码编写顺序无关)。我们程序控制的只是输出结果,而不是线程的执行的执行顺序。
模拟还原线程执行过程:
-
情景一
(1) 假设第一次抢占成功的是线程A,线程A获得锁,此时state=0,符合state%3==0的条件,那么执行i自增(记录A的打印次数),state自增,为state = 1,并执行输出语句 System.out.println(“A”),控制台输出A,然后是执行输出语句System.out.println(“ThreadA”),最后是线程A释放掉锁。
(2) 进入下一轮锁的争夺,此时我们期望是线程B能抢到锁,但是(通过打印结果可以看到)实际还是ThreadA抢占到了锁,因为此时state=1,不满足while的判断条件,所以控制台只会输出ThreadA。
(3) 直到线程B抢占成功,线程B获得锁,此时state=1,符合state%3==1的条件,那么执行i自增(记录B的打印次数),state自增,为state = 2,并执行输出语句 System.out.println(“B”),没控制台输出B,然后是执行输出语句System.out.println(“ThreadB”),最后是线程B释放掉锁。
(4) 进入下一轮锁争夺重复,此时我们期望是线程C能抢到锁,但是(通过打印结果可以看到)实际还是ThreadB抢占到了锁,因为此时state=2,不满足while的判断条件,所以控制台只会输出ThreadB。
(5) 直到线程C抢占成功,线程C获得锁,此时state=2,符合state%3==2的条件,那么执行i自增(记录C的打印次数),state自增,为state = 3,并执行输出语句 System.out.println(“C”),没控制台输出C,然后是执行输出语句System.out.println(“ThreadC”),最后是线程C释放掉锁。
那么此时第一轮ABC的循环已经分析完成,接下来的就是重复执行步骤(1)~(5) -
情景二
(1) 假设第一次抢占成功的是线程C,线程C获得锁,此时state=0,不符合state%3==2的条件执行输出语句System.out.println(“ThreadC”),最后是线程C释放掉锁
(2) 进入下一轮锁的争夺,此时我们期望是线程A能抢到锁,但是(通过打印结果可以看到)实际还是ThreadC抢占到了锁,因为此时state=0,不满足while的判断条件,所以控制台只会输出ThreadC。
(3)直到线程A抢占成功,线程A获得锁,此时state=0,符合state%3==0的条件,那么执行i自增(记录A的打印次数),state自增,为state = 1,并执行输出语句 System.out.println(“A”),没控制台输出A,然后是执行输出语句System.out.println(“ThreadA”),最后是线程A释放掉锁。
步骤(3)已经与情景一的情况基本一致,所有接下执行的步骤参考情景一的(2)~(5)
至此,我们基本分析完线程的执行过程,通过这种方式我们发现,线程的执行不是很高效或者说不够“智能”,因为在执行第一遍循环ABC的时候,线程A、线程B和线程C可能都执行了很多遍,线程的每一次执行都要经历获取锁和释放锁的过程,而且线程的状态也需要发生变化,即每多执行一遍就有一次相应的开销,所以这种方式的性能开销比较大,那有什么好的优化方式呢?在下一种方法中我们引入了Condition,来控制线程
通过ReentrantLock、状态位、Conidton来实现
public class ThreadABCWithCondition {
// 锁
private static ReentrantLock lock = new ReentrantLock();
// 条件
private static Condition conditionA = lock.newCondition();
private static Condition conditionB = lock.newCondition();
private static Condition conditionC = lock.newCondition();
// 状态位
private static int state = 0;
// 计数器
private static CountDownLatch countDownLatch = new CountDownLatch(3);
static class ThreadA extends Thread {
@Override
public void run() {
try {
lock.lock();
for (int i = 0; i < 3;) {
while (state % 3 != 0) {
// 当不符合该线程执行条件时
System.out.println("Why A");
conditionA.await();
}
conditionB.signal();
state++;
i++;
System.out.println("A");
// conditionA.await();
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
countDownLatch.countDown();
}
}
static class ThreadB extends Thread {
@Override
public void run() {
try {
lock.lock();
for (int i = 0; i < 3;) {
while (state % 3 != 1) {
// 当不符合该线程执行条件时
System.out.println("Why B");
conditionB.await();
}
conditionC.signal();
state++;
i++;
System.out.println("B");
// conditionB.await();
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
countDownLatch.countDown();
}
}
static class ThreadC extends Thread {
@Override
public void run() {
try {
lock.lock();
for (int i = 0; i < 3;) {
while (state % 3 != 2) {
// 当不符合该线程执行条件时
System.out.println("Why C");
conditionC.await();
}
conditionA.signal();
state++;
i++;
System.out.println("C");
// conditionC.await();
}
} catch (Exception e) {
e.printStackTrace();
} finally {
lock.unlock();
}
countDownLatch.countDown();
}
}
public static void main(String[] args) throws InterruptedException {
long start= System.currentTimeMillis();
new ThreadC().start();
new ThreadA().start();
new ThreadB().start();
countDownLatch.await();
System.out.println("打印耗时:"+(System.currentTimeMillis()-start)+"ms");
}
}
输出结果:
通过控制台打印篇幅来看,使用Condition之后,输出打印明显减少,而且通过执行时间也可以看出,执行效率有所提升。
使用Condition后,锁竞争的过程如下:
模拟还原线程执行过程:
(1)首先线程C获取到了锁,此时state=0,符合while的判断条件,所以会输出“Why C”,并且执行await(),将线程C的锁释放掉,并且线程C的状态变为waiting状态并进入Condition的等待队列。
(2)进入下一轮锁竞争,此时只有线程B和线程A有获取锁的资格,若线程B获取,执行过程同过程(1),输出“Why B”,并且执行await(),将线程的B锁释放掉,并且线程B的状态变为waiting状态并进入Condition的等待队列。
(3)进入下一轮锁竞争,此时只有线程A有获取锁的资格,线程A获取锁,state=0,不会执行while里的代码,i自增,state自增,唤醒线程B,线程B进入Runnable状态,并输出“A”,紧接着会进入下一次for循环,此时state=1,会进入执行while里面的逻辑,输出“Why A”,并且将线程A进行挂起并释放持有的锁。
(4)进入下一轮锁竞争,此时只有线程B有获取锁的资格,线程B获取锁,state=1,不会执行while里的代码,i自增,state自增,唤醒线程C,线程C进入Runnable状态,并输出“B”,紧接着会进入下一次for循环,此时state=2,会进入执行while里面的逻辑,输出“Why B”,并且将线程B进行挂起并释放持有的锁。
(5)进入下一轮锁竞争,此时只有线程C有获取锁的资格,线程C获取锁,state=2,不会执行while里的代码,i自增,state自增,唤醒线程A,线程A进入Runnable状态,并输出“C”,紧接着会进入下一次for循环,此时state=3,会进入执行while里面的逻辑,输出“Why C”,并且将线程C进行挂起并释放持有的锁。
(6)继续循环步骤(3)~(5),直到完成打印