阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载，保留摘要，谢谢！

• 先说结论
• 字节码验证：眼见为实
• 为什么是同一个东西
• 那该选哪个？
• 面试官真正想听的

---

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
3. 您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。
4. 新的源码解析文章实时收到通知。每周更新一篇左右。
5. 认真的源码交流微信群。

---

先说结论

while(true) 和 for(;;) 性能完全一致，零区别。 这是一道经典的”伪性能”面试题。

如果你面试时一本正经地分析哪个快 0.00001 纳秒，面试官心里大概率在想：”这位对性能优化的理解，还停留在表面。”

字节码验证：眼见为实

不信？写段代码自己验：

public class LoopTest {
    public void whileLoop() {
        while (true) {
            // do something
        }
    }

    public void forLoop() {
        for (;;) {
            // do something
        }
    }
}

执行 javac LoopTest.java，再用 javap -c LoopTest 反编译，你会看到两个方法的字节码一模一样——核心就是一条 goto 指令，无条件跳回循环开头。就这么朴实无华。

为什么是同一个东西

两层原因：

第一层：javac 编译阶段。 for(;;) 没有初始化、没有条件判断、没有迭代语句，javac 直接将它编译为无条件跳转——和 while(true) 的处理方式完全一致。编译器不傻，它看到的就是”死循环”，管你用什么语法写的。

第二层：JIT 运行时优化。 即使字节码层面有微小差异（实际没有），JVM 的 JIT 编译器（C2/Graal）在将热点代码编译成本地机器码时，也会抹平一切。JIT 做的优化比这复杂几个数量级——循环展开、逃逸分析、内联缓存——它根本不关心你的死循环是用 while 还是 for 写的。

那该选哪个？

优先用 while(true)。

理由很简单：while(true) 的语义一目了然——“永远循环”。而 for(;;) 三个光秃秃的分号，第一眼看过去总要愣一下。这种写法来自 C 语言的老传统，在 JDK 源码里确实不少见（比如 java.util.concurrent 包里），但那是历史风格，不是你要模仿的理由。

代码是写给人看的，顺便让机器执行。 团队代码规范怎么定就怎么写，但如果没有明确规范，while(true) 永远是更安全的选择。

面试官真正想听的

这道题是个筛选器，面试官想看你能不能跳出”微观性能对比”的陷阱。

回答的正确姿势是：先用两句话说清楚”字节码一样，没有性能差异”，然后主动把话题引向真正重要的性能优化方向——算法复杂度、I/O 瓶颈、锁竞争、数据库慢查询、缓存策略。

最怕的回答是什么？是一脸严肃地说”for(;;) 比 while(true) 少一次条件判断所以更快”。这种回答暴露了两个问题：一是没看过字节码，二是把”性能优化”理解成了”抠语法细节”。真正吃性能的从来不是这种地方，而是你的 SQL 有没有走索引、你的线程池配没配对、你的序列化方案选没选好。

把时间花在刀刃上，别在螺丝钉上卷。