这其实是Android ART虚拟机的JIT（即时编译）优化在“搞鬼”，也是你看到首次启动和重启应用后行为差异的核心原因。

具体原因拆解 #

1. 首次启动：JIT尚未优化空循环 #

第一次打开应用时，ART虚拟机还没对这段空循环代码做即时编译，会老老实实逐行执行for (int i = 0; i < 100000000; i++) ;，这个空循环确实会消耗约1秒时间，所以消息发送间隔符合预期。

2. 重启应用：JIT完成了“无效代码消除”优化 #

当你通过最近任务列表或启动器重启应用时，Android系统大概率会保留原进程的缓存（避免频繁创建进程的开销），此时ART已经对这段空循环代码完成了JIT编译。编译器会发现这个循环没有任何实际副作用（既不修改外部变量，也不产生可观测的结果），于是直接把整个循环优化掉——相当于这段代码根本不会执行，自然没有延迟，线程会疯狂发送消息，导致Logcat被刷屏。

3. 为什么Thread.sleep(1000)不受影响？ #

Thread.sleep()是Java原生方法，它的作用是让线程强制暂停指定时间，这个行为是明确且有副作用的（线程阻塞），JIT编译器不会对它进行优化，所以无论首次启动还是重启，都会严格等待1秒再发送消息，间隔保持稳定。

验证方法 #

如果你想确认是JIT优化的问题，可以试试这两种方式：

• 在开发者选项中开启“禁用JIT编译”，重启应用后空循环会恢复延迟；
• 给空循环加一个有实际意义的操作，避免被优化：

// 替换空循环，加入实际计算
long sum = 0;
for (int i = 0; i < 100000000; i++) {
    sum += i;
}
// 打印sum或赋值给外部变量，防止被编译器优化
Log.d("test", "loop sum: " + sum);

正确的替代方案 #

用空循环模拟长任务非常不可靠，因为JIT优化会让它的行为完全不可预测。推荐几种更稳定的方式：

• 用Thread.sleep(long)模拟固定延迟，这是最直接可靠的选择；
• 如果是实际业务中的耗时任务，确保任务包含真实的计算、IO操作（比如文件读写、网络请求）；
• 考虑使用更优雅的定时API，比如Handler.postDelayed()、ScheduledExecutorService，它们比手动管理线程+循环更易维护且稳定。

补充：代码中的小细节优化 #

你的onDestroy()中调用mThread.interrupt()是正确的，但要注意：空循环被优化后执行极快，Thread.interrupted()可能无法及时检测到中断信号；如果换成Thread.sleep()，睡眠时会直接抛出InterruptedException，能更及时响应中断。

内容的提问来源于stack exchange，提问作者tronman