小伙伴們好呀，最近在重新復(fù)習(xí)，整理自己的知識(shí)庫(kù)，偶然看到這道面試題：三個(gè)線程按順序打印 ABCABC，嘗試著做一下，才發(fā)現(xiàn)自己對(duì)線程還有好多地方不懂，藍(lán)瘦…… ??
思路
很明顯，這里就涉及線程間相互通信的知識(shí)了。
而相互通信的難點(diǎn)就是要控制好，阻塞和喚醒的時(shí)機(jī)。
一. 這里就是 A 通知 B，B 通知 C , C 通知 A
二. 三個(gè)線程在等待（阻塞）和喚醒（執(zhí)行） 中不斷切換。
三. 等待的方式大致分為兩種
- wait 方法 (Object native 方式 )
- LockSupport.park 方式 ( Unsafe native 方式 )
四. 喚醒的方式
- notify,notifyAll 方法 (Object native 方式 )
- LockSupport.unPark 方式 ( Unsafe native 方式 )
五. 互斥條件
線程 A 先拿到資源 c，再拿資源 a ，[a 執(zhí)行完后釋放，并喚醒等待資源 a] 的 線程 B 線程 B 先拿到資源 a，再拿資源 b ，[b 執(zhí)行完后釋放，并喚醒等待資源 b] 的 線程 C 線程 C 先拿到資源 b，再拿資源 c ，[c 執(zhí)行完后釋放，并喚醒等待資源 c] 的 線程 A
所以得有 三個(gè) 共享資源 abc 來(lái)達(dá)到互斥條件
Synchronized 還是 ReentrantLock 都得建立 三個(gè)共享資源
六. 擴(kuò)展
使用 LockSupport ，如果要像上面這樣子的思路去解答，就得注意 線程相互引用行成的循環(huán)依賴(lài)問(wèn)題，這里借用 Spring 的思路 用 Map 巧妙化解。
或者做法2 通過(guò) 外部的成員變量，不斷地去判斷，unpark 線程 a b c
Synchronized 方式
private static class MySynchronized {
void printABC() throws InterruptedException {
class MyRunable implements Runnable {
private Object lock1;
private Object lock2;
private CountDownLatch countDownLatch;
public MyRunable(Object lock1, Object lock2){
this.lock1 = lock1;
this.lock2 = lock2;
}
public MyRunable(Object lock1, Object lock2, CountDownLatch countDownLatch){
this.lock1 = lock1;
this.lock2 = lock2;
this.countDownLatch = countDownLatch;
}
@Override
public void run(){
boolean running = false;
int count = 2;
while (count > 0) {
// C,A - > A 喚醒 B 線程
// A,B - > B 喚醒 C 線程
// B,C - > C 喚醒 A 線程 (最后一次執(zhí)行時(shí)，喚醒 A 后，A 發(fā)現(xiàn) count =0，就不執(zhí)行了。
synchronized (lock1) {
synchronized (lock2) {
System.out.println(Thread.currentThread().getName());
count--;
// lock2 方法塊執(zhí)行結(jié)束前，喚醒其他線程。
lock2.notify();
}
// 線程執(zhí)行完畢后
if (countDownLatch != null && !running) {
countDownLatch.countDown();
running = true;
}
try {
// 釋放鎖
lock1.wait();
} catch (InterruptedException e) {
}
}
}
System.out.println(Thread.currentThread().getName() + " over");
synchronized (lock2) {
// 喚醒其他線程。
lock2.notify();
}
}
}
CountDownLatch countDownLatch = new CountDownLatch(1);
CountDownLatch countDownLatch2 = new CountDownLatch(1);
Object a = new Object();
Object b = new Object();
Object c = new Object();
MyRunable ra = new MyRunable(c, a, countDownLatch);
MyRunable rb = new MyRunable(a, b, countDownLatch2);
MyRunable rc = new MyRunable(b, c);
Thread a1 = new Thread(ra, "A");
a1.start();
countDownLatch.await();
Thread b1 = new Thread(rb, "B");
b1.start();
countDownLatch2.await();
Thread c1 = new Thread(rc, "C");
c1.start();
}
}這里我借用 countDownLatch 去控制線程的啟動(dòng)流程，盡量不使用 Thread.sleep() 來(lái)實(shí)現(xiàn)，拿捏線程的執(zhí)行，通信步驟。
寫(xiě)這個(gè)的時(shí)候，除了一開(kāi)始思路不清晰外，還出現(xiàn)一個(gè)小狀況，就是 程序執(zhí)行完卡住了。
debug 發(fā)現(xiàn)線程 B C 還在 wait 狀態(tài)，這是寫(xiě)時(shí)候容易疏忽的。
要記得在循環(huán)外再次喚醒其他線程，讓他們走完方法。
ReentrantLock 方式
private static class MyReentrantLock {
int number = 6;
void printABC(){
ReentrantLock lock = new ReentrantLock();
Condition conditionA = lock.newCondition();
Condition conditionB = lock.newCondition();
Condition conditionC = lock.newCondition();
class MyRunnable implements Runnable {
ReentrantLock lock;
Condition condition1;
Condition condition2;
public MyRunnable(ReentrantLock lock, Condition condition1, Condition condition2){
this.lock = lock;
this.condition1 = condition1;
this.condition2 = condition2;
}
@Override
public void run(){
int count = 2;
while (count > 0) {
lock.lock();
try {
String name = Thread.currentThread().getName();
if (
number % 3 != 0 && "A".equals(name)
|| number % 3 != 2 && "B".equals(name)
|| number % 3 != 1 && "C".equals(name)
) {
condition1.await();
}
System.out.println(name + " : " + number);
number--;
count--;
condition2.signal();
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
}
new Thread(new MyRunnable(lock, conditionC, conditionA), "A").start();
new Thread(new MyRunnable(lock, conditionA, conditionB), "B").start();
new Thread(new MyRunnable(lock, conditionB, conditionC), "C").start();
}
}Synchronized 會(huì)了之后，這個(gè)也很簡(jiǎn)單了。
就是上鎖的地方換成 lock.lock();，把三個(gè)共享資源換成 lock.newCondition();
然后思考一下阻塞條件 condition1.await() 。
畢竟 打印 和 喚醒 的操作總是在一起的。
Semaphore 我也寫(xiě)了，但是感覺(jué)不太適合，畢竟它的作用是用來(lái)控制并發(fā)線程數(shù)的，我直接創(chuàng)建三個(gè) Semaphore 總覺(jué)得怪怪的。??
LockSupport 方式
這里我寫(xiě)了兩種方法
private static class MyLockSupport {
volatile int number = 6;
void printABC() throws InterruptedException {
class MyRunnable implements Runnable {
@Override
public void run(){
int count = 2;
while (count > 0) {
LockSupport.park(this);
System.out.println(Thread.currentThread().getName());
count--;
}
}
}
Thread a = new Thread(new MyRunnable(), "A");
Thread b = new Thread(new MyRunnable(), "B");
Thread c = new Thread(new MyRunnable(), "C");
a.start();
b.start();
c.start();
while (number > 0) {
if (number % 3 == 0) {
LockSupport.unpark(a);
} else if (number % 3 == 2) {
LockSupport.unpark(b);
} else {
LockSupport.unpark(c);
}
number--;
LockSupport.parkNanos(this, 200 * 1000);
// LockSupport.parkUntil(this,System.currentTimeMillis()+3000L);
}
}
// 用 map 解決線程循環(huán)依賴(lài)的問(wèn)題
void printABC2() throws InterruptedException {
class MyRunnable implements Runnable {
Map<String, Thread> map;
public MyRunnable(Map<String, Thread> map){
this.map = map;
}
@Override
public void run(){
int count = 2;
String name = Thread.currentThread().getName();
String key = "A".equals(name) ? "B" : "B".equals(name) ? "C" : "A";
while (count > 0) {
if (
number % 3 == 0 && "A".equals(name)
|| number % 3 == 2 && "B".equals(name)
|| number % 3 == 1 && "C".equals(name)
) {
System.out.println(name);
count--;
number--;
LockSupport.unpark(map.get(key));
}
LockSupport.park(this);
}
LockSupport.unpark(map.get(key));
}
}
Map<String, Thread> map = new HashMap<>();
Thread a = new Thread(new MyRunnable(map), "A");
Thread b = new Thread(new MyRunnable(map), "B");
Thread c = new Thread(new MyRunnable(map), "C");
map.put("A", a);
map.put("B", b);
map.put("C", c);
a.start();
b.start();
c.start();
}
}LockSupport 我也是第一次用，它使用起來(lái)也很方便，就單純的 阻塞和喚醒線程 ，對(duì)應(yīng) park 和 unPark 方法。
它不要求你像 wait 那樣子，必須寫(xiě)在 Synchronized 代碼塊里，被 Monitor 監(jiān)視才行。
但同時(shí)，也意味著你必須控制好這個(gè) 鎖的范圍 。
你可以自由阻塞代碼，在具備某個(gè)條件時(shí)，喚醒特定的線程，讓它繼續(xù)執(zhí)行。
實(shí)際上，上面 ReentrantLock 中的 Condition await 方法，底層就是調(diào)用 LockSupport 的 park 方法。
這也是我開(kāi)頭說(shuō)的通信大致分為兩種方式的原因。
方法一中，我是用 parkNanos 阻塞一段時(shí)間，然后就繼續(xù)運(yùn)行，也算是取巧不用 Thread.Sleep 了吧??
方法二 我比較喜歡，思路也是同開(kāi)頭兩種，打印完喚醒其他線程。
