写个续集，填坑来了！关于“Thread.sleep(0)这一行‘看似无用’的代码”里面留下的坑。

🚀 优质资源分享 🚀

你好呀，我是居家十三天只出了一次小区门的歪歪。

这篇文章是来填坑的，我以前写文章的时候也会去填之前的一些坑，但是由于拖延症，大多都会隔上上几个月。

这次这个坑比较新鲜，就是之前发布的《没有二十年功力，写不出这一行“看似无用”的代码！》这篇文章，太多太多的朋友看完之后问出了一个相同的问题：

首先非常感谢阅读我文章的朋友，同时也特别感谢阅读的过程中带着自己的思考，提出有价值的问题的朋友，这对我而言是一种正反馈。

我当时写的时候确实没有想到这个问题，所以当突然问起的时候我大概知道原因，由于未做验证，所以也不敢贸然回答。

于是我寻找了这个问题的答案，所以先说结论：

就是和 JIT 编译器有关。由于循环体中的代码被判定为热点代码，所以经过 JIT 编译后 getAndAdd 方法的进入安全点的机会被优化掉了，所以线程不能在循环体能进入安全点。

是的，被优化了，我打这个词都感觉很残忍。

接下来我准备写个“下集”，告诉你我是怎么得到这个结论的。但是为了让你丝滑入戏，我先带你简单的回顾一下“上集”。

另外，先把话说在前面，这知识点吧，属于可能一辈子都遇不到的那种。因此我把它划分到我写的“没有卵用系列”，看着也就图一乐。

好了，在之前的那篇文章中，我给出了这样的一个测试用例：

public class MainTest {

    public static AtomicInteger num = new AtomicInteger(0);

    public static void main(String[] args) throws InterruptedException {
        Runnable runnable=()->{
            for (int i = 0; i < 1000000000; i++) {
                num.getAndAdd(1);
            }
            System.out.println(Thread.currentThread().getName()+"执行结束!");
        };

        Thread t1 = new Thread(runnable);
        Thread t2 = new Thread(runnable);
        t1.start();
        t2.start();
        Thread.sleep(1000);
        System.out.println("num = " + num);
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

按照代码来看，主线程休眠 1000ms 后就会输出结果，但是实际情况却是主线程一直在等待 t1,t2 执行结束才继续执行。

运行结果是这样的：

其实我在这里埋了“彩蛋”，这个代码虽然你直接粘贴过去就能跑，但是如果你的 JDK 版本高于 10，那么运行结果就和我前面说的不一样了。

从结果来看，还是有不少人挖掘到了这个“彩蛋”：

所以看文章的时候，有机会自己亲自验证一下，说不定会有意外收获的。

针对程序表现和预期不一致的问题，第一个解决方案是这样的：

把 int 修改为 long 就搞定了。至于为什么，之前的文章中已经说明了，这里就不赘述了。

关键的是下面这个解决方案，所有的争议都围绕着它展开。

受到 RocketMQ 源码的启示，我把代码修改为了这样：

从运行结果上来看 ，即使 for 循环的对象是 int 类型，也可以按照预期执行。

为什么呢？

因为在上集中关于 sleep 我通过查阅资料得出了这样的两个结论：

• 1.正在执行 native 函数的线程可以看作“已经进入了safepoint”。
• 2.由于 sleep 方法是 native 的，所以调用 sleep 方法的线程会进入 Safepoint。

论点清晰、论据合理、推理完美、事实清楚，所以上集演到这里就结束了…

直到，有很多朋友问出了这个问题：

可是 n