乐趣区

关于java:线程池中的一个-BUG注意了

jiezi

起源：https://segmentfault.com/a/11…

问题形容

前几天在帮共事排查生产一个线上偶发的线程池谬误

逻辑很简略，线程池执行了一个带后果的异步工作。然而最近有偶发的报错：

java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@a5acd19 rejected from java.util.concurrent.ThreadPoolExecutor@30890a38[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]

本文中的模仿代码曾经问题都是在 HotSpot java8 (1.8.0_221)版本下模仿 & 呈现的

上面是模仿代码，通过 Executors.newSingleThreadExecutor 创立一个单线程的线程池，而后在调用方获取 Future 的后果

public class ThreadPoolTest {public static void main(String[] args) {final ThreadPoolTest threadPoolTest = new ThreadPoolTest();
        for (int i = 0; i < 8; i++) {new Thread(new Runnable() {
                @Override
                public void run() {while (true) {Future<String> future = threadPoolTest.submit();
                        try {String s = future.get();
                        } catch (InterruptedException e) {e.printStackTrace();
                        } catch (ExecutionException e) {e.printStackTrace();
                        } catch (Error e) {e.printStackTrace();
                        }
                    }
                }
            }).start();}
        
        // 子线程不停 gc，模仿偶发的 gc
        new Thread(new Runnable() {
            @Override
            public void run() {while (true) {System.gc();
                }
            }
        }).start();}

    /**
     * 异步执行工作
     * @return
     */
    public Future<String> submit() {
        // 关键点，通过 Executors.newSingleThreadExecutor 创立一个单线程的线程池
        ExecutorService executorService = Executors.newSingleThreadExecutor();
        FutureTask<String> futureTask = new FutureTask(new Callable() {
            @Override
            public Object call() throws Exception {Thread.sleep(50);
                return System.currentTimeMillis() + "";}
        });
        executorService.execute(futureTask);
        return futureTask;
    }

}

剖析 & 疑难

第一个思考的问题是：线程池为什么敞开了，代码中并没有手动敞开的中央。看一下 Executors.newSingleThreadExecotor 的源码实现：

public static ExecutorService newSingleThreadExecutor() {
    return new FinalizableDelegatedExecutorService
            (new ThreadPoolExecutor(1, 1,
                    0L, TimeUnit.MILLISECONDS,
                    new LinkedBlockingQueue<Runnable>()));
}

这里创立的实际上是一个 FinalizableDelegatedExecutorService，这个包装类重写了finalize 函数，也就是说这个类会在被 GC 回收之前，先执行线程池的 shutdown 办法。

问题来了，GC 只会回收不可达（unreachable）的对象 ，在submit 函数的栈帧未执行完出栈之前，executorService应该是可达的才对。

更多多线程系列教程：https://www.javastack.cn/cate…

对于此问题，先抛出论断：

当对象仍存在于作用域（stack frame）时，finalize也可能会被执行

oracle jdk 文档中有一段对于 finalize 的介绍：

A reachable object is any object that can be accessed in any potential continuing computation from any live thread.

Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner.

大略意思是：可达对象 (reachable object) 是能够从任何流动线程的任何潜在的继续拜访中的任何对象；java 编译器或代码生成器可能会对不再拜访的对象提前置为 null，使得对象能够被提前回收

也就是说，在 jvm 的优化下，可能会呈现对象不可达之后被提前置空并回收的状况

举个例子来验证一下，摘自：https://stackoverflow.com/que…

class A {@Override protected void finalize() {System.out.println(this + "was finalized!");
    }

    public static void main(String[] args) throws InterruptedException {A a = new A();
        System.out.println("Created" + a);
        for (int i = 0; i < 1_000_000_000; i++) {if (i % 1_000_00 == 0)
                System.gc();}
        System.out.println("done.");
    }
}

// 打印后果
Created A@1be6f5c3
A@1be6f5c3 was finalized!//finalize 办法输入
done.

从例子中能够看到，如果 a 在循环实现后曾经不再应用了，则会呈现先执行 finalize 的状况；尽管从对象作用域来说，办法没有执行完，栈帧并没有出栈，然而还是会被提前执行。

当初来减少一行代码，在最初一行打印对象 a，让编译器 / 代码生成器认为前面有对象 a 的援用

...
System.out.println(a);

// 打印后果
Created A@1be6f5c3
done.
A@1be6f5c3

从后果上看，finalize 办法都没有执行（因为 main 办法执行实现后过程间接完结了），更不会呈现提前 finalize 的问题了

基于下面的测试后果，再测试一种状况，在循环之前先将对象 a 置为 null，并且在最初打印放弃对象 a 的援用

A a = new A();
System.out.println("Created" + a);
a = null;// 手动置 null
for (int i = 0; i < 1_000_000_000; i++) {if (i % 1_000_00 == 0)
        System.gc();}
System.out.println("done.");
System.out.println(a);

// 打印后果
Created A@1be6f5c3
A@1be6f5c3 was finalized!
done.
null

从后果上看，手动置 null 的话也会导致对象被提前回收，尽管在最初还有援用，但此时援用的也是 null 了

当初再回到下面的线程池问题，依据下面介绍的机制，在剖析没有援用之后，对象会被提前 finalize

可在上述代码中，return 之前明明是有援用的executorService.execute(futureTask)，为什么也会提前 finalize 呢？

猜想可能是因为在 execute 办法中，会调用 threadPoolExecutor，会创立并启动一个新线程，这时会产生一次被动的线程切换，导致在流动线程中对象不可达

联合下面 Oracle Jdk 文档中的形容“可达对象 (reachable object) 是能够从任何流动线程的任何潜在的继续拜访中的任何对象”，能够认为可能是因为一次显示的线程切换，对象被认为不可达了，导致线程池被提前 finalize 了

上面来验证一下猜测：

// 入口函数
public class FinalizedTest {public static void main(String[] args) {final FinalizedTest finalizedTest = new FinalizedTest();
        for (int i = 0; i < 8; i++) {new Thread(new Runnable() {
                @Override
                public void run() {while (true) {TFutureTask future = finalizedTest.submit();
                    }
                }
            }).start();}
        new Thread(new Runnable() {
            @Override
            public void run() {while (true) {System.gc();
                }
            }
        }).start();}
    public TFutureTask submit(){TExecutorService TExecutorService = Executors.create();
        TExecutorService.execute();
        return null;
    }
}

//Executors.java，模仿 juc 的 Executors
public class Executors {
    /**
     * 模仿 Executors.createSingleExecutor
     * @return
     */
    public static TExecutorService create(){return new FinalizableDelegatedTExecutorService(new TThreadPoolExecutor());
    }

    static class FinalizableDelegatedTExecutorService extends DelegatedTExecutorService {FinalizableDelegatedTExecutorService(TExecutorService executor) {super(executor);
        }
        
        /**
         * 析构函数中执行 shutdown，批改线程池状态
         * @throws Throwable
         */
        @Override
        protected void finalize() throws Throwable {super.shutdown();
        }
    }

    static class DelegatedTExecutorService extends TExecutorService {

        protected TExecutorService e;

        public DelegatedTExecutorService(TExecutorService executor) {this.e = executor;}

        @Override
        public void execute() {e.execute();
        }

        @Override
        public void shutdown() {e.shutdown();
        }
    }
}

//TThreadPoolExecutor.java，模仿 juc 的 ThreadPoolExecutor
public class TThreadPoolExecutor extends TExecutorService {

    /**
     * 线程池状态，false：未敞开，true 已敞开
     */
    private AtomicBoolean ctl = new AtomicBoolean();

    @Override
    public void execute() {
        // 启动一个新线程，模仿 ThreadPoolExecutor.execute
        new Thread(new Runnable() {
            @Override
            public void run() {}
        }).start();
        // 模仿 ThreadPoolExecutor，启动新建线程后，循环查看线程池状态，验证是否会在 finalize 中 shutdown
        // 如果线程池被提前 shutdown，则抛出异样
        for (int i = 0; i < 1_000_000; i++) {if(ctl.get()){throw new RuntimeException("reject!!!["+ctl.get()+"]");
            }
        }
    }

    @Override
    public void shutdown() {ctl.compareAndSet(false,true);
    }
}

执行若干工夫后报错：

Exception in thread "Thread-1" java.lang.RuntimeException: reject!!![true]

从谬误上来看，“线程池”同样被提前 shutdown 了，那么肯定是因为新建线程导致的吗？

上面将新建线程批改为 Thread.sleep 测试一下：

//TThreadPoolExecutor.java，批改后的 execute 办法
public void execute() {
    try {
        // 显式的 sleep 1 ns，被动切换线程
        TimeUnit.NANOSECONDS.sleep(1);
    } catch (InterruptedException e) {e.printStackTrace();
    }
    // 模仿 ThreadPoolExecutor，启动新建线程后，循环查看线程池状态，验证是否会在 finalize 中 shutdown
    // 如果线程池被提前 shutdown，则抛出异样
    for (int i = 0; i < 1_000_000; i++) {if(ctl.get()){throw new RuntimeException("reject!!!["+ctl.get()+"]");
        }
    }
}

执行后果一样是报错

Exception in thread "Thread-3" java.lang.RuntimeException: reject!!![true]

由此可得，如果在执行的过程中，产生一次显式的线程切换，则会让编译器 / 代码生成器认为外层包装对象不可达

总结

尽管 GC 只会回收不可达 GC ROOT 的对象，然而在编译器（没有明确指出，也可能是 JIT）/ 代码生成器的优化下，可能会呈现对象提前置 null，或者线程切换导致的“提前对象不可达”的状况。

所以如果想在 finalize 办法里做些事件的话，肯定在最初显示的援用一下对象（toString/hashcode 都能够），放弃对象的可达性（reachable）

下面对于线程切换导致的对象不可达，没有官网文献的反对，只是集体一个测试后果，如有问题欢送指出

综上所述，这种回收机制并不是 JDK 的 bug，而算是一个优化策略，提前回收而已；但 Executors.newSingleThreadExecutor 的实现里通过 finalize 来主动敞开线程池的做法是有 Bug 的，在通过优化后可能会导致线程池的提前 shutdown，从而导致异样。

线程池的这个问题，在 JDK 的论坛里也是一个公开但未解决状态的问题：https://bugs.openjdk.java.net…。

不过在 JDK11 下，该问题曾经被修复：

JUC  Executors.FinalizableDelegatedExecutorService
public void execute(Runnable command) {
    try {e.execute(command);
    } finally {reachabilityFence(this); }
}

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

退出移动版