多线程编程

Thread类基础

Q： Thread的deprecated过期方法是哪3个？作用是啥
A：

stop()，终止线程的执行。
suspend()，暂停线程执行。
resume()，恢复线程执行。

Q：废弃stop的原因是啥？
A：
调用stop时，会直接终止线程并释放线程上已锁定的锁，线程内部无法感知，并且不会做线程内的catch操作！即线程内部不会处理stop后的烂摊子，相当于是强制终止。如果其他线程等在等着上面的锁去取数据，那么拿到的可能是一个半成品。

变成题目的话应该是下面这样，问会输出什么？

public class Test {

    public static void main(String[] args) throws InterruptedException {

        System.out.println("start");
        Thread thread = new MyThread();
        thread.start();
        Thread.sleep(1000); // 等待一段时间保证线程运行起来
        thread.stop(); // 不建议这么做
        // thread.interrupt(); // 推荐的方式

    }
}

class MyThread extends Thread {
    public void run() {
        try {
            System.out.println("run");
            Thread.sleep(5000); // 模拟一些长时间的任务
        } catch (InterruptedException e) {
            // 处理烂摊子,清理资源
            System.out.println("clear resource!");
        }
    }
}

答案是输出 start和run，但是不会输出clear resource

Q： stop的替代方法是什么？
A： interrupt()
调用thread.interrupt()终止时，不会直接释放锁，它仅仅只是通知线程您好需要终止了，让线程有机会执行一些后续操作，同时也可以无视这个通知。有两种方式接收通知：一种是异常，另一种是主动检测。

通过异常的方式，前提是当线程要处于WAITING、 TIMED_WAITING状态时，其他线程调用该线程的interrupt方法时，才会产生InterruptedException异常。如上题的代码把thread.stop()改成thread.interrupt()后，在线程的Thread.sleep(5000)过程中就会抛出interrupException，因此会输出clear resource

但如果处于RUNNABLE状态，并且没有阻塞在某个I/O操作，就只能依赖线程自己主动检测中断状态了。上题的例子中，如果线程中没有做sleep操作，那么就需要用isInterrupted()/interrupted()来判断自己这个线程是否被终止了，来做清理。

class MyThread extends Thread {
    public void run() {
        while (true) {
            System.out.println("run");
            // TODO 一些非阻塞的任务，线程一直处于RUNNABLE状态
            if (Thread.currentThread.isInterrupted()) {
                break;
            }
        }
    }
}

isInterrupted()和interrupted的区别

// interrupted为静态方法，用法为Thread.interrupted();
public static boolean interrupted() {
    return currentThread().isInterrupted(true); // 重置当前线程的中断状态
}

// isInterrupted是实例方法，用法为Thread.currentThread.isInterrupted()
public boolean isInterrupted() {
    return isInterrupted(false); // 不会清除当前线程的中断状态
}

Q： suspend/resume的废弃原因是什么？
A：：调用suspend不会释放锁。
如果线程A暂停后，他的resume是由线程B来调用的，但是线程B又依赖A里的某个锁，那么就死锁了。
例如下面这个例子，就要知道会引发死锁：

public class Test {
    public static Object lockObject = new Object(); // 主线程和MyThread共用一个锁对象
    public static void main(String[] args) throws InterruptedException {

        System.out.println("start");
        Thread thread = new MyThread();
        thread.start();
        Thread.sleep(1000);

        System.out.println("主线程试图占用lockObject锁资源");
        synchronized (Test.lockObject) {
            // 用Test.lockObject做一些事
            System.out.println("做一些事");
        }
        System.out.println("恢复");
        thread.resume();

    }
}

class MyThread extends Thread {
    public void run() {
        try {
            synchronized (Test.lockObject) {
                System.out.println("占用Test.lockObject");
                suspend();
            }
            System.out.println("MyThread恢复执行");
        }
        catch (Exception e){}
    }
}

答案输出：

start
占用Test.lockObject
主线程试图占用lockObject锁资源

由于MyThread线程suspend()时只是进入了休眠状态，并未释放所持有的锁对象，导致主线程一直在等待锁的释放，程序进入死锁状态。

Q：上题的suspend和resume可以怎么替换，来解决死锁问题？
A：可以用wait和noitfy来处理

public class Test {
    public static Object lockObject = new Object(); // 主线程和MyThread共用一个锁对象
    public static void main(String[] args) throws InterruptedException {

        Thread thread = new MyThread();
        thread.start();
        Thread.sleep(1000);

        System.out.println("主线程试图占用lockObject锁资源");
        synchronized (Test.lockObject) {
            Test.lockObject.notify(); // 主线程会通知其他等待锁的线程可以获得锁对象，但要将锁内的代码执行完后，才会交出锁的控制权
            System.out.println("做一些事"); // 用Test.lockObject做一些事
        }

    }
}

class MyThread extends Thread {
    public void run() {
        try {
            synchronized (Test.lockObject) {
                System.out.println("占用Test.lockObject");
                Test.lockObject.wait(); // 释放锁对象，线程进入休眠状态
            }
            System.out.println("MyThread恢复执行"); // 线程重新持有锁对象，恢复执行
        }
        catch (Exception e){}
    }
}

如此执行，结果正常：

占用Test.lockObject
主线程试图占用lockObject锁资源
做一些事
MyThread恢复执行

当我们使用wait()方法时，会释放锁对象后，让线程A进入休眠状态，这样便能让其他需要使用锁的线程能够获取到锁的控制权，而不会出现死锁的现象。
线程B拿到锁后，在任务即将完成时，可以使用notify()发起通知（随机唤醒一个wait的线程），表示我用完了，你可以醒啦，来进行锁的竞争。
线程A醒了以后，等待着线程B完成任务后，交出了锁的控制权，于是马上争抢持有了锁对象，恢复程序的执行
线程A运行结束

而notifyAll()是针对线程池中存在多个休眠的线程的情况，notifyAll()会将所有处于锁对象的线程全部唤醒，同时进行锁的争夺。换言之，所谓唤醒线程，另一种解释可以说是将线程由等待池移动到锁池，notifyAll调用后，会将全部线程由等待池移到锁池，然后参与锁的竞争，竞争成功则继续执行，如果不成功则留在锁池等待锁被释放后再次参与竞争。而notify只会唤醒一个线程

Q:用一个形象的故事说明一下wait和notify的意义

https://blog.csdn.net/x541211190/article/details/109258676

例：捡肥皂的故事
假设有两个程序员去洗澡，只带了一块肥皂，两个人怎么使用一块肥皂洗澡呢？会发生3个场景：

1.老王和老李（专家程序员）：
老王和老李随机一人拿到肥皂，比如老王先拿到肥皂，然后使用肥皂，然后把肥皂让出去，自己等会再用。老李拿到了肥皂，然后使用了一会，再通知老王说：“自己不用了”，老王听到话以后，捡起肥皂从上次用的地方接着用。二者洗澡，你来我往共享一块肥皂，非常和谐。

程序语言描述：
老王随机先得到锁，然后用了一会后，调用了wait()方法，把锁交了出去，自己等待。老李拿到锁，使用后，再通过notify()通知老王，然后等老李用完以后，老王再次拿到锁，继续执行…这种方式是线程安全的，而且还能合理的分配资源的使用，这就是等待唤醒的好处。

2.王哥和李哥（普通程序员）:
王哥和李哥随机一人拿到肥皂，比如王哥先拿到，然后王哥就一直霸占着，直到自己洗完了，才把肥皂给李哥。期间李哥洗澡只能干搓，根本没机会接触肥皂。我想李哥肯定觉得王哥很自私，不懂得礼让，李哥的体验不是很好。

程序语言描述：王哥和李哥就是两个线程，王哥在拿到锁以后，就一直使用，直到同步代码块中的内容完全执行完成。再把锁交给李哥使用。这种方式每次都是一个线程执行完，另一个才会执行，是线程安全的。

3.小王和小李（新手程序员）：
小王和小李一开始洗澡就争抢肥皂，当肥皂在小王手上时，小王还在使用中，小李就扑上来了，于是出现了两人一起摩擦一块肥皂的场景！这种画面既不优雅，也不安全。

程序语言描述：
如果两个线程，访问同一个资源的时候，不对其进行加锁控制，就会出现混乱的场景，这就是线程不安全。两个线程可能会同时操作同一共享变量，从而使这个共享变量失控，最终结果紊乱。

Q：下面这例子为什么会运行异常，抛出IllegalMonitorStateException错误？

public static void main(String[] args) throws InterruptedException {
    Thread thread = new MyThread();
    thread.start();
    thread.notify();
}

A： notify和wait的使用前提是必须持有这个对象的锁，即main代码块需要先持有thread对象的锁，才能使用notify去唤醒（wait同理）。
改成下面就行了

Thread thread = new MyThread();
thread.start();
synchronized (thread) {
    thread.notify();
}

Q: 为什么wait必须持有锁的时候才能调用？
A:
因为wait和notify是组合使用的。

一般是到了一定条件例如缺少资源、缺乏某个前置动作时，才会进入wait。
这时候生产资源的那个线程生产了新资源后，就会调用notify方法，告诉另一个线程，我做好了，你可以动身了。
但如果我们不先加同步块，就可能导致 wait之前的判断条件有问题，比如运行顺序为：（1）A线程先判断缺资源，（2）然后切到B线程做了资源生产并notify，（3）切回A线程进入wait状态。这时候再wait已经没有意义了, 永远收不到notify。 “即如果不在同步块中，则wait的判断条件或者wait时机可能是有问题的！”

参考文章：为什么WAIT必须在同步块中

Q： Thread.sleep()和Object.wait()的区别
A：
sleep不会释放对象锁，而wait会释放对象锁。

Q: 如果有3个线程同时抢占了这个锁且都在wait，我希望只notify唤醒某个线程，怎么办？
A:

使用LockSupport, 可以unPark指定的线程。
使用Lock + Condition 实现唤醒指定的部分线程。即锁是同一个，但是可以针对锁生成的特定condition做唤醒

wait() 和 notify() 方法是 Object 的方法，而 await() 和 signal() 方法是接口 Condition 的方法

Q: LockSupport相比notify/wait有什么优点？
A:

LockSupport不需要在同步代码块里。所以线程间也不需要维护一个共享的同步对象了，实现了线程间的解耦。
unpark函数可以先于park调用，所以不需要担心线程间的执行的先后顺序。

Q：Runnable接口和Callable的区别。
A： Callable可以和Futrue配合，并且启动线程时用的时call，能够拿到线程结束后的返回值，call方法还能抛出异常。

Q：thread.alive()表示线程当前是否处于活跃/可用状态。thread.start()后，是否alive()一定返回true？
活跃状态：线程已经启动且尚未终止。线程处于正在运行或准备开始运行的状态，就认为线程是“存活的

public class Main {
    public static void main(String[] args) {
        TestThread tt = new TestThread();
        System.out.println("Begin == " + tt.isAlive());
        tt.start();
        System.out.println("end == " + tt.isAlive());
    }
}

A:
不一定，有可能在打印时，线程已经运行结束了，或者start后，还未真正启动起来（就是还没进入到run中）

Q: 线程A如下，把线程A作为构造参数，传给线程B，此时对B线程打印this.isAlive会显示什么？：

public class A extends Thread {
    
    public void run() {
        System.out.println("this.isAlive()=" + this.isAlive());
    }
}
A a = new A();
Thread b = new Thread(a);
b.start()

A：
此时会打印false!

因为把a作为构造参数传入b中，b执行start时，实际上是在B线程中去调用了A对象的run方法，而不是启用了A线程。
如果改成

A a = new A();
a.start()

那么就会打印true了

Q：把FutureTask放进Thread中，并start后，会正常执行callable里的内容吗？

public static void main(String[] args) throws Exception {
    Callable<Integer> callable = () -> {
    System.out.println("call 100");
    return 100;
    };
    
    FutureTask<Integer> task = new FutureTask<>(callable);
    Thread thread = new Thread(task);
    thread.start();
}

A：
能正常打印

synchronized关键字

即可作为方法的修饰符，也可以作为代码块的修饰符
注意修饰方法时，并不是这个方法上有锁，而是调用该方法时，需要取该方法所在对象上的锁。

class A{
     synchroized f(){
     }   
}

即调用这个f()，并不是说f同一时刻只能进入一次，而是说进入f时，需要取到A上的锁。

Q：调用下面的f()时，会出现死锁吗？

class A{
     synchroized f(){
        t()
     }
    
     synchroized t(){
     }
}

A：不会。
1个线程内，可以重复进入1个对象的synchroized 块。

原理：
当线程请求自己的锁时。JVM会记下锁的持有者，并且给这个锁计数为1。
如果该线程再次请求自己的锁，则可以再次进入，计数为2.
退出时计数-1.
直到全部退出时才会释放锁。

目的是为了避免死锁。万一 1个对象在sync方法中调用另一个sync方法，如果是非重入的，就可能导致自己把自己锁住了。

sync和JUC-Lock都是可重入锁，原理类似。

Q:2个线程同时调用f1和f2会产生同步吗？

class A{
    private static synchronized void f1(){};
    private synchronized void f2(){};
}

A:
不会产生同步。二者不是1个锁。
f1是类锁，等同于synchronized(A.class)
f2是对象锁。

其他的同步工具

CountDownLatch

final CountDownLatch latch = new CountDownLatch(2);

2是计数器初始值。
然后执行latch.await()时，就会阻塞，直到其他线程中把这个latch进行latch.countDown()，并且计数器降低至0。

CountDownLatch和join的区别：join阻塞时，是只等待单个线程的完成，而CountDownLatch可能是为了等待多个线程

Q： countDownLatch的内部计数值能被重置吗？#
A：
不能重置了。如果要重新计数必须重新new一个。毕竟他的类名就叫DownLatch

FutureTask

可以理解为一个支持有返回值的线程

FutureTask<Integer> task = new FutureTask<>(runable);

当调用task.get()时，就能取到线程里的返回值

Q：调用futrueTask.get()时，这个是阻塞方法吗？如果是阻塞，什么时候会结束？
A：
是阻塞方法。

线程跑完并返回结果
阻塞时间达到futrueTask.get(xxx)里设定的xxx时间
线程出现异常InterruptedException或者ExecutionException
线程被取消，抛出CancellationException

Semaphore

就是操作系统里常见的那个概念，java实现，用于各线程间进行资源协调。
用Semaphore(permits)构造一个包含permits个资源的信号量
然后某线程做了消费动作，则执行semaphore.acquire()，则会消费一个资源
如果某线程做了生产动作，则执行semaphore.release()，则会释放一个资源（即新增一个资源）
更详细的信号量方法说明：
https://blog.csdn.net/hanchao5272/article/details/79780045

Q：信号量中，公平模式和非公平模式的区别？下面设成true就是公平模式

//new Semaphore(permits,fair):初始化许可证数量和是否公平模式的构造函数
semaphore = new Semaphore(5, true);

A：
其实就是使用哪种公平锁还是非公平锁。

Java并发中的NonfairSync（非公平）和fairSync（公平）主要区别为：

如果当前线程不是锁的占有者,则NonfairSync并不判断是否有等待队列,直接使用compareAndSwap去进行锁的占用,即谁正好抢到，就给谁用！
如果当前线程不是锁的占有者,则FairSync则会判断当前是否有等待队列,如果有则将自己加到等待队列尾，即严格的先到先得！

CyclicBarrier （栅栏）

栅栏，一般是在线程中去调用的
它的构造需要指定1个线程数量，和栅栏被破坏前要执行的操作
每当有1个线程调用barrier.await()，就会进入阻塞，同时barrier里的线程计数-1。
当线程计数为0时，调用栅栏里指定的那个操作后，然后破坏栅栏，所有被阻塞在await上的线程继续往下走。

Exchanger （交换栅栏）

我理解为两方栅栏，用于交换数据。
简单说就是一个线程在完成一定的事务后，想与另一个线程交换数据
则第一个先拿出数据的线程会一直等待第二个线程，直到第二个线程拿着数据到来时才能彼此交换对应数据

原子类AtomicXXX

就是内部已实现了原子同步机制

Q：下面输出什么？（考察getAndAdd的用法）

AtomicInteger num = new AtomicInteger(1);
System.out.println(num.getAndAdd(1));
System.out.println(num.get());

A：
输出1、2
顾名思义， getAndAdd(),那么就是先get，再加，类似于num++。
如果是addAndGet()，那么就是++num

Q：AtomicReference和AtomicInteger的区别？
A：
AtomicInteger是对整数的封装，而AtomicReference则对应普通的对象引用。也就是它可以保证你在修改对象引用时的线程安全性。
即可能会有多个线程修改atomicReference里包含的引用。

经典用法：

boolean exchanged = atomicStringReference.compareAndSet(initialReference, newReference)

就是经典的CAS同步法。compreAndSet它会将将引用与预期值（引用）进行比较，如果它们相等，则在AtomicReference对象内设置一个新的引用。类似于一个非负责的自旋锁。

AtomicReferenceArray是原子数组，可以进行一些原子的数组操作例如 set(index, value)

java中已实现的全部原子类中没有float、short和byte。

Q：什么是乐观锁和悲观锁，简单讲一下概念？

参考文章：https://javaguide.cn/java/concurrent/optimistic-lock-and-pessimistic-lock.html

如果将悲观锁（Pessimistic Lock）和乐观锁（PessimisticLock 或 OptimisticLock）对应到现实生活中来。悲观锁有点像是一位比较悲观（也可以说是未雨绸缪）的人，总是会假设最坏的情况，避免出现问题。乐观锁有点像是一位比较乐观的人，总是会假设最好的情况，在要出现问题之前快速解决问题。

悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。像 Java 中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。在 Java 中java.util.concurrent.atomic包下面的原子变量类（比如AtomicInteger、LongAdder）就是使用了乐观锁的一种实现方式 CAS 实现的。

线程池

Q: ThreadPoolExecutor线程池构造参数中，corePoolSize和maximumPoolSize有什么区别？
A：
当提交新线程到池中时

如果当前线程数 < corePoolSize，则会创建新线程
如果当前线程数 = corePoolSize，则新线程被塞进一个队列中等待。
如果队列也被塞满了，那么又会开始新建线程来运行任务，避免任务阻塞或者丢弃
如果队列满了的情况下，线程总数超过了maxinumPoolSize，那么就抛异常或者阻塞（取决于队列性质）。

Q：线程池的keepalive参数是干嘛的？
A：当线程数量在corePoolSize到maxinumPoolSize之间时，如果有线程已跑完，且空闲时间超过keepalive时，则会被清除（注意只限于corePoolSize到maxinumPoolsize之间的线程）

Q: 核心线程可以被回收吗？（线程池没有被回收的情况下）
A:
ThreadPoolExecutor有个allowCoreThreadTimeOut(boolean value)方法，可以设置是否在超期后做回收

Q: 那这个线程数设置多少，你是怎么考虑的呢？
A:
io密集型，可以设置多一点，因为多一个线程，他可能也没太占cpu，都是在等待IO。
如果是计算密集型，则要设置少一点，别把cpu搞满载了。

有超线程技术的话，一般可以设置成2倍CPU数量的线程数

超线程技术把多线程处理器内部的两个逻辑内核模拟成两个物理芯片，让单个处理器就能使用线程级的并行计算，进而兼容多线程操作系统和软件。超线程技术充分利用空闲CPU资源，在相同时间内完成更多工作。

Q：线程池有哪三种队列策略？
A：

握手队列：相当于不排队的队列。可能造成线程数量无限增长直到超过maxinumPoolSize（相当于corePoolSize没什么用了，只以maxinumPoolSize做上限）
无界队列：队列长度无限，即线程数量达到corePoolSize时，后面的线程只会在队列中等待。（相当于maxinumPoolSize没什么用了）。缺陷：可能造成队列无限增长以至于OOM。代码安全静态扫描时这是其中一条扫描项。
有界队列：队列长度有限，队列满后，开始新建线程运行任务，达到maximuPoolSize后阻塞或者抛异常

Q：线程池队列已满且maxinumPoolSize已满时，有哪些拒绝策略？
A：

AbortPolicy 默认策略：直接抛出RejectedExecutionException异常
DiscardPolicy 丢弃策略：直接丢了，什么错误也不报
DiscardOldestPolicy 丢弃队头策略：即把最先入队的人从队头扔出去，再尝试让该任务进入队尾（队头任务内心：不公平。。。。）
CallerRunsPolicy 调用者处理策略：交给调用者所在线程自己去跑任务（即谁调用的submit或者execute，他就自己去跑） 注意这个策略会用的比较多
也可以用实现自定义新的RejectedExecutionHandler

Q: 线程池为什么需要阻塞队列？
A:
线程池创建线程需要获取mainlock这个全局锁，影响并发效率，阻塞队列可以很好的缓冲。避免大量线程获取这个创建锁。

Q：有以下五种Executor提供的线程池，注意记忆一下他们的用途，就能理解内部的原理了。
A:
在阿里巴巴Java开发手册中，是禁止使用这五种线程池，因为他们对线程池的资源没有做限制，有OOM的风险：

newCachedThreadPool：缓存线程池
- corePoolSize=0, maxinumPoolSize=+∞，队列长度=0 ，
- 因此线程数量会在corePoolSize到maxinumPoolSize之间一直灵活缓存和变动，且不存在队列等待的情况，一来任务我就创建，用完了会释放。
newFixedThreadPool ：定长线程池
- corePoolSize= maxinumPoolSize=构造参数值，队列长度=+∞。
- 因此不存在线程不够时扩充的情况
newScheduledThreadPool :定时器线程池
- 提交定时任务用的，构造参数里会带定时器的间隔和单位。其他和FixedThreadPool相同，属于定长线程池。
newSingleThreadExecutor : 单线程池
- corePoolSize=maxinumPoolSize=1，队列长度=+∞
- 只会跑一个任务，所以其他的任务都会在队列中等待，因此会严格按照FIFO执行
newWorkStealingPool（继承自ForkJoinPool ）：并行线程池
- 如果你的任务执行时间很长，并且里面的任务运行并行跑的，那么他会把你的线程任务再细分到其他的线程来分治。
- ForkJoinPool介绍：https://blog.csdn.net/m0_37542889/article/details/92640903

Q： submit和execute的区别是什么？
A:

execute只能接收Runnable类型的任务，而submit除了Runnable，还能接收Callable（Callable类型任务支持返回值）
execute方法返回void， submit方法返回FutureTask。
异常方面， submit方法因为返回了futureTask对象，而当进行future.get()时，会把线程中的异常抛出，因此调用者可以方便地处理异常。（如果是execute，只能用内部捕捉或者设置catchHandler）

Q：线程池中， shutdown、 shutdownNow、awaitTermination的区别？
A：

shutdown: 停止接收新任务，等待所有池中已存在任务完成（ 包括等待队列中的线程 ）。异步方法，即调用后马上返回。
shutdownNow: 停止接收新任务，并 停止所有正执行的task，返回还在队列中的task列表。
awaitTermination： 仅仅是一个判断方法，判断当前线程池任务是否全部结束。一般用在shutdown后面，因为shutdown是异步方法，你需要知道什么时候才真正结束。

Thread状态转换

https://blog.csdn.net/qq_22771739/article/details/82529874

Q：线程的6种状态是：
A：

New：新建了线程，但是还没调用start
RUNNABLE：运行，就绪状态包括在运行态中
BLOCKED：阻塞，一般是因为想拿锁拿不到
WAITING：等待，一般是wait或者join之后
TIMED_WAITING: 定时等待，即固定时间后可返回，一般是调用sleep或者wait(时间)的。
TERMINATED：终止状态。

Q： java线程什么时候会进入阻塞（可能按多选题考）：
A：

sleep
wait()挂起，等待获得别的线程发送的Notify()消息
等待IO
等待锁

Volatile

用volatile修饰成员变量时，一旦有线程修改了变量，其他线程可立即看到改变。

Q：不用volatile修饰成员变量时，为什么其他线程会无法立即看到改变？
A：
线程可以把变量保存在本地内存（比如机器的寄存器）中，而不是直接在主存中进行读写。
这就可能造成一个线程在主存中修改了一个变量的值，而另外一个线程还继续使用它在寄存器中的变量值。

Q：用了volatile是不是就可以不用加锁啦？
A：不行。

锁并不是只保证1个变量的互斥，有时候是要保证几个成员在连续变化时，让其他线程无法干扰、读取。
而volatile保证1个变量可变，保证不了几个变量同时变化时的原子性。

Q: volatile变量如果定义的太多会发生什么？
A:
volatile有嗅探机制，如果定义过多，可能会引发总线风暴，导致性能下降。

线程群组

为了方便管理一批线程，我们使用ThreadGroup来表示线程组，通过它对一批线程进行分类管理
使用方法：

Thread group = new ThreadGroup("group");
Thread thread = new Thread(gourp, ()->{..});

即thread除了Thread(Runable)这个构造方法外，还有个Thread(ThreadGroup, Runnable)构造方法

Q：在线程A中创建线程B，他们属于同一个线程组吗
A：
是的

线程组的一大作用是对同一个组线程进行统一的异常捕捉处理，避免每次新建线程时都要重新去setUncaghtExceptionHandler。即线程组自身可以实现一个uncaughtException方法。

ThreadGroup group = new ThreadGroup("group") {
    
    public void uncaughtException(Thread thread, Throwable throwable) {
        System.out.println(thread.getName() + throwable.getMessage());
        }
    };
}

线程如果抛出异常，且没有在线程内部被捕捉，那么此时线程异常的处理顺序是什么？

相信很多人都看过下面这段话，好多讲线程组的博客里都这样写：

首先看看当前线程组（ThreadGroup）有没有父类的线程组，如果有，则使用父类的UncaughtException()方法。
如果没有，就看线程是不是调用setUncaughtExceptionHandler()方法建立Thread.setUncaughtExceptionHandler实例。如果建立，直接使用它的UncaughtException()方法处理异常。
如果上述都不成立就看这个异常是不是ThreadDead实例，如果是，什么都不做，如果不是，输出堆栈追踪信息（printStackTrace）。

来源：
https://blog.csdn.net/qq_43073128/article/details/90597006
https://blog.csdn.net/qq_43073128/article/details/88280469

好，别急着记，先看一下下面的题目，问输出什么：
Q:

// 父类线程组
static class GroupFather extends ThreadGroup {
    public GroupFather(String name) {
        super(name);
    }
    
    public void uncaughtException(Thread thread, Throwable throwable) {
        System.out.println("groupFather=" + throwable.getMessage());
    }
}

public static void main(String[] args) {
    // 子类线程组
    GroupFather groupSon = new GroupFather("groupSon") {
        
        public void uncaughtException(Thread thread, Throwable throwable) {
            System.out.println("groupSon=" + throwable.getMessage());
        }
    };


    Thread thread1 = new Thread(groupSon, ()->{
        throw new RuntimeException("我异常了");
    });
    thread1.start();
}

A：
一看（1），那是不是应该输出groupFather?
错错错，输出的是groupSon这句话在很多地方能看到，但没有去实践过看过源码的人就会这句话被误导。
实际上父线程组不是指类继承关系上的线程组，而是指的是构造关系的有父子关系。
如果子类的threadGroup没有去实现uncaughtException方法，那么就会去构造参数里指定的父线程组去调用方法。

Q：那我改成构造关系上的父子关系，下面输出什么？

public static void main(String[] args) {
    // 父线程组
    ThreadGroup groupFather = new ThreadGroup("groupFather") {
        
        public void uncaughtException(Thread thread, Throwable throwable) {
            System.out.println("groupFather=" + throwable.getMessage());
        }
    };

    // 子线程组,把groupFather作为parent参数
    ThreadGroup groupSon = new ThreadGroup(groupFather, "groupSon") {
        
        public void uncaughtException(Thread thread, Throwable throwable) {
            System.out.println("groupSon=" + throwable.getMessage());
        }
    };

    Thread thread1 = new Thread(groupSon, ()->{
        throw new RuntimeException("我异常了");
    });

    thread1.start();
}

A：
答案输出：groupSon=我异常了
即只要子线程组有实现过，则会用子线程组里的方法，而不是直接去找的父线程组！

Q：如果我让自己做set捕捉器的操作呢？那下面这个输出什么？

public static void main(String[] args) {
    // 父线程组
    ThreadGroup group = new ThreadGroup("group") {
        
        public void uncaughtException(Thread thread, Throwable throwable) {
            System.out.println("group=" + throwable.getMessage());
        }
    };

    // 建一个线程，在线程组内
    Thread thread1 = new Thread(group, () -> {
        throw new RuntimeException("我异常了");
    });

    // 自己设置setUncaughtExceptionHandler方法
    thread1.setUncaughtExceptionHandler((t, e) -> {
        System.out.println("no gourp:" + e.getMessage());
    });

    thread1.start();
}

A:
看之前的结论里，似乎是应该输出线程组的异常？
但是结果却输出的是：no group:我异常了

也就是说，如果线程对自己特地执行过setUncaughtExceptionHandler，那么有优先对自己设置过的UncaughtExceptionHandler做处理。

那难道第（2）点这个是错的吗？确实错了，实际上第二点应该指的是全局Thread的默认捕捉器，注意是全局的
实际上那段话出自ThreadGroup里uncaughtException的源码：

这里就解释了之前的那三点，但是该代码中没考虑线程自身设置了捕捉器

修改一下之前的总结一下线程的实际异常抛出判断逻辑：

如果线程自身有进行过setUncaughtExceptionHandler,则使用自己设置的那个。
如果没设置过，则看一下没有线程组。并按照以下逻辑判断:
1. 如果线程组有覆写过uncaughtException，则用覆写过的uncaughtException
2. 如果线程组没有覆写过，则去找父线程组（注意是构造体上的概念）的uncaughtException方法。
如果线程组以及父类都没覆写过uncaughtException，则判断是否用Thread.setDefaultUncaughtExceptionHandler(xxx)去设置全局的默认捕捉器，有的话则用全局默认
如果不是ThreadDeath线程，则只打印堆栈。
如果是ThreadDeath线程，那么就什么也不处理。

本博客文章除特别声明外，均可自由转载与引用，转载请标注原文出处：http://www.yelbee.top/index.php/archives/216/

文章目录