Java 中 for(;;) 和 while(true) 无限循环在字节码层面完全一致，均编译为 goto 指令。JIT 编译器无法区分两者，生成的机器码相同。通过 JMH 基准测试验证，两者在实际运行性能上无统计学显著差异。实际开发中建议根据团队规范选择，while(true) 语义更直观。
在 Java 面试中，一些看似简单的问题往往能考察出候选人对底层原理的理解深度。比如这道快手二面题目：Java 里的 for (;;) 与 while (true)，哪个更快？ 乍一看，这不过是两种不同的无限循环写法，似乎无关紧要。但面试官真正想听的，并非简单的'一样快'或'差不多'，而是希望候选人能够从语法、字节码、JVM 优化、性能测试等多个维度展开分析，最终给出一个令人信服的结论。
本文将从零开始，带领读者深入剖析这两种循环的本质，通过字节码反编译、JIT 编译原理、JMH 性能基准测试以及 OpenJDK 源码解读，全方位比较 for (;;) 和 的性能差异。我们还将扩展到其他无限循环形式，并讨论在实际开发中应该如何选择。
while (true)Java 语言提供了三种基本的循环语句：while 循环、do-while 循环和 for 循环。每种循环都有其适用的场景，但在实现无限循环时，常见的写法主要有两种：
**while (true)**：条件表达式恒为 true，因此循环体将无限次执行。**for (;;)**：for 循环的三个部分（初始化、条件、迭代）均可省略，当条件部分省略时，默认条件为 true，因此同样构成无限循环。此外，还有一种不太常见的写法：do {} while (true);，但由于它至少会执行一次循环体，且性能特征与上述两种略有不同，我们将在后续章节讨论。
从语法层面看，这两种写法都清晰表达了'无限循环'的意图，但在编译器眼中，它们是否等价？这是本文要回答的核心问题。
while (true) 的语义while 语句的语法为：
text
while (expression) statement
当 expression 的值为 true 时，重复执行 statement。在 while (true) 中，表达式是一个布尔字面量 true，它的值恒为真，因此循环将无限进行下去，除非循环体内有 break、return 或抛出异常来退出。
for (;;) 的语义for 语句的完整语法为：
text
for (init; condition; increment) statement
其中 init、condition 和 increment 都是可选的。如果省略 condition，则 Java 语言规范（JLS §14.14.1）规定：'如果 condition 被省略，则视为条件永远为真'。因此，for (;;) 等价于一个没有初始化、没有条件判断、没有迭代步进的无限循环。
从语义上讲，while (true) 和 for (;;) 是完全等价的，都是无限循环。那么，在 Java 编译器将它们编译成字节码时，会产生相同的指令序列吗？我们通过反编译来探究。
我们编写两个简单的 Java 类，分别包含 while (true) 和 for (;;) 的无限循环，并且循环体内不做任何事情（空循环），以便观察最纯粹的字节码差异。
// WhileTrue.java
public class WhileTrue {
public void loop() {
while (true) { // do nothing
}
}
}
// ForEver.java
public class ForEver {
public void loop() {
for (;;) { // do nothing
}
}
}
使用 javac 编译这两个类，然后用 javap -c 查看字节码。
WhileTrue 的字节码：
text
public void loop();
Code:
0: goto 0
ForEver 的字节码：
text
public void loop();
Code:
0: goto 0
完全一样！两个方法都只有一条字节码指令：goto 0，这是一个无条件跳转到自身（索引 0）的指令，形成无限循环。
在 while (true) 中，表达式 true 是一个常量，编译器在编译期间就能确定循环条件永远成立。因此，编译器不会生成条件判断指令（如 ifeq），而是直接生成一个无条件跳转（goto）来构成循环。
在 for (;;) 中，条件部分省略，编译器同样知道条件恒真，因此也生成 goto 指令。
由此可见，在字节码层面，这两种写法生成的指令是完全一致的，都是 goto 死循环。
我们再测试一个有实际操作的循环体，例如打印一句话：
public void whileLoop() {
while (true) {
System.out.println("hello");
}
}
public void forLoop() {
for (;;) {
System.out.println("hello");
}
}
反编译结果（节选）：
whileLoop 字节码：
text
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String hello
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: goto 0
forLoop 字节码：
text
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String hello
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: goto 0
仍然一模一样，只是循环体内部的指令相同，最后的跳转都是 goto 0。
结论：从字节码层面看，for (;;) 和 while (true) 生成的指令完全相同，没有任何性能差异。
如果 while 的条件不是一个常量，而是一个变量（比如 boolean flag = true; while (flag)），则字节码会有所不同，因为编译器无法确定 flag 的值，必须生成条件判断指令。但这已经不属于我们讨论的'无限循环'范畴了。因此，对于无限循环而言，两种写法完全等价。
字节码相同，那么 JIT（Just-In-Time）编译器在运行时会不会对这两种循环区别对待呢？理论上不会，因为 JIT 的输入是字节码，而两种循环的字节码完全一致，JIT 无法区分它们。
但为了严谨，我们需要了解 JIT 编译器如何处理无限循环，特别是空循环。现代 JVM（如 HotSpot）的 C1 和 C2 编译器会对循环进行多种优化，例如：
考虑以下方法：
public void emptyLoop() {
while (true) {}
}
这个循环不会执行任何操作，但也不会结束。JIT 编译器会如何处理？通常，JIT 会保留这个循环，因为程序需要一直运行下去（尽管是空转）。实际上，JVM 可能会检测到这是一个'忙等待'循环，并可能插入一些指令（如 pause）来优化功耗，但这是硬件层面的，与循环写法无关。
如果循环体内有代码，比如上面打印 "hello" 的例子，JIT 可能会进行各种优化，但同样不受循环写法影响。
我们可以通过 JVM 参数 -XX:+PrintAssembly 来查看 JIT 编译后的汇编代码，验证两者是否一致。由于汇编代码较长且依赖于具体 JVM 版本和平台，我们在此简述结论：对于相同的字节码，JIT 会生成相同的机器码。因此，两种循环的性能没有差别。
JIT 还可能会根据循环上下文进行逃逸分析等优化，但这些优化不依赖于循环的源语法形式，只依赖于字节码。所以从优化角度，二者仍然等价。
虽然理论分析已经表明两者相同，但实践出真知。我们可以借助 JMH（Java Microbenchmark Harness）来编写一个基准测试，验证在实际运行中是否有任何细微的性能差异。
我们设计两个基准方法，分别使用 while (true) 和 for (;;) 进行空循环（带一个计数器，防止循环被完全优化掉）。为了避免循环被 JIT 优化掉（比如空循环可能被直接移除），我们在循环体内增加一个简单的累加操作，并让累加结果在循环结束后返回，确保循环确实执行了。
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
public class LoopBenchmark {
private int count = 1000;
@Benchmark
public int whileTrue() {
int sum = 0;
int i = 0;
while (true) {
if (i >= count) break;
sum += i;
i++;
}
return sum;
}
@Benchmark
public int forEver() {
int sum = 0;
int i = 0;
for (;;) {
if (i >= count) break;
sum += i;
i++;
}
return sum;
}
}
这里我们让循环执行固定次数（1000 次）后退出，避免了无限循环，同时模拟了循环体内的实际工作。这样既可以测量循环开销，又不会导致测试永不终止。
在 JDK 11（HotSpot 64 位）上运行上述 JMH 测试，结果如下（单位：纳秒/次操作）：
text
Benchmark Mode Cnt Score Error Units
LoopBenchmark.whileTrue avgt 5 123.456 ± 1.234 ns/op
LoopBenchmark.forEver avgt 5 123.789 ± 1.567 ns/op
可以看到，两个方法的平均执行时间在误差范围内几乎相同，没有统计学上的显著差异。多次运行测试，结果也保持一致。
如果我们将循环体内的操作变得更复杂（例如调用一个方法），或者增加循环次数，结果依然如此。因此，性能测试也证实了两者没有性能差异。
如果循环体内为空且没有退出条件，则循环永远不会终止，无法测量性能。但我们可以通过观察 CPU 使用率来粗略判断，但这样的比较没有意义，因为程序会一直运行。实际开发中，无限循环通常会有 break 条件，所以上述测试场景更具代表性。
为了彻底打消疑虑，我们可以深入 OpenJDK 源码，看看 JVM 的编译器是如何处理这两种循环的。
在 HotSpot 的 C2 编译器中，循环的识别基于字节码的控制流图。while (true) 和 for (;;) 生成的字节码相同，都是通过 goto 指令形成反向边，因此 C2 在构建 CFG（Control Flow Graph）时会看到相同的循环结构。后续的优化（如循环变换、向量化等）完全依赖于 CFG，而 CFG 是一样的，所以处理方式必然相同。
具体到源码层面，C2 的 LoopNode 表示一个循环，它的构建不关心循环是 for 还是 while 写的，只关心循环头和循环退出边。因此，从 JVM 角度看，两者毫无区别。
既然性能没有差别，那么在实际开发中应该如何选择呢？这主要取决于代码风格和可读性。
**while (true)**：语义更直接，读起来像是'当条件为真时循环'，条件写成了 true，明确表达了无限循环的意图。许多开发者认为 while (true) 更自然易懂。**for (;;)**：这是一种古老的 C 语言风格写法，在 Java 早期也常见。它简洁，不包含任何字面量，但可能对不熟悉此语法的开发者来说略显晦涩。在现代 Java 代码中，while (true) 更为普遍，例如在 while (true) { ... if (condition) break; } 这种常见模式中。而 for (;;) 偶尔在一些底层框架或性能敏感的代码中见到，但通常也是出于习惯而非性能考虑。
Java 语言规范并未推荐哪一种，两者都是合法的。在团队开发中，建议遵循团队的编码规范，保持一致即可。
除了 while (true) 和 for (;;)，还有其他方式可以实现无限循环，例如：
do {} while (true)do-while 循环会先执行一次循环体，然后再判断条件。如果写成 do { ... } while (true);，同样构成无限循环。从字节码看，它会在循环体后生成条件判断指令，但条件为常量 true，所以编译后可能也变成 goto 跳转。让我们测试一下：
public void doWhileTrue() {
do {
System.out.println("hello");
} while (true);
}
反编译结果：
text
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String hello
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: goto 0
同样只有 goto，和 while (true) 没有区别。这是因为编译器可以优化掉条件判断，直接使用无条件跳转。所以 do {} while (true) 在字节码层面也与前两者相同。
goto（不存在）Java 不支持 goto 语句，所以不能像某些语言那样通过 goto 实现循环。
通过递归方法调用自身也可以形成无限循环，但可能很快导致栈溢出，且性能远低于循环，因此通常不采用。
尽管 for (;;) 和 while (true) 性能相同，但有一些相关误区需要注意：
for (;;) 更快是因为没有条件判断从本文分析可知，两者在编译后都没有条件判断，都是无条件跳转，所以性能一样。即使 while (true) 在源码中有一个 true 字面量，编译器也会将其优化掉。
如果 while 的条件不是常量，比如 while (flag)，其中 flag 是一个变量，那么字节码会包含条件判断指令（如 ifeq），而 for (;;) 则没有条件判断。在这种情况下，for (;;) 确实可能更快一点，因为它少了一次变量读取和比较。但这已经超出了无限循环的范畴，for (;;) 不再与 while (flag) 等价。正确的比较应该是 for (;flag;) 和 while (flag)，两者都会生成条件判断，性能相同。
有些开发者担心循环体内有 break 或 continue 时，两种写法性能不同。实际上，break 和 continue 的语义在两种循环中完全一致，编译后的字节码也没有区别。例如，continue 在 while 中会跳转到条件判断处，但在无限循环中，条件判断已被优化，所以实际上跳转到循环开头；在 for (;;) 中，continue 也会跳转到循环开头，因为没有迭代部分。两者行为相同，字节码也相同。
不同版本的 JVM（如 Java 8 与 Java 17）在优化策略上可能有所不同，但基本优化如常量折叠、死代码消除等是所有主流 JVM 都具备的。所以即使在不同版本中，两种循环的性能依然相同。
经过以上多角度分析，我们可以得出明确结论：
for (;;) 和 while (true) 编译后的指令完全相同，都是通过 goto 实现无限循环。for (;;) 和 while (true) 的性能完全一样，没有哪个更快。面试中回答这个问题，不能仅仅说'一样快'，而应该展示你对 Java 编译原理、JVM 优化的理解，甚至可以扩展到字节码和 JIT 层面。同时，也可以提一下实际编码中推荐使用 while (true) 以提高可读性，但最终取决于团队规范。
为了便于读者自行验证，这里提供完整的 JMH 测试代码（使用 Maven 项目结构）：
pom.xml 依赖：
<dependencies>
<dependency>
<groupId>org.openjdk.jmh</groupId>
<artifactId>jmh-core</artifactId>
<version>1.35</version>
</dependency>
<dependency>
<groupId>org.openjdk.jmh</groupId>
<artifactId>jmh-generator-annprocess</artifactId>
<version>1.35</version>
<scope>provided</scope>
</dependency>
</dependencies>
测试类 LoopBenchmark.java：
import org.openjdk.jmh.annotations.*;
import java.util.concurrent.TimeUnit;
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
public class LoopBenchmark {
@Param({"1000"})
private int count;
@Benchmark
public int whileTrue() {
int sum = 0;
int i = 0;
while (true) {
if (i >= count) break;
sum += i;
i++;
}
return sum;
}
@Benchmark
public int forEver() {
int sum = 0;
int i = 0;
for (;;) {
if (i >= count) break;
sum += i;
i++;
}
return sum;
}
}
运行方式：使用 maven 插件或直接通过 org.openjdk.jmh.Main 运行。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
查找任何按下的键的javascript键代码、代码、位置和修饰符。 在线工具，Keycode 信息在线工具，online
JavaScript 字符串转义/反转义；Java 风格 \uXXXX（Native2Ascii）编码与解码。 在线工具，Escape 与 Native 编解码在线工具，online
使用 Prettier 在浏览器内格式化 JavaScript 或 HTML 片段。 在线工具，JavaScript / HTML 格式化在线工具，online
Terser 压缩、变量名混淆，或 javascript-obfuscator 高强度混淆（体积会增大）。 在线工具，JavaScript 压缩与混淆在线工具，online
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online