java游戏循环需固定时间步长解耦逻辑与渲染，用纳秒级计时+防负休眠控制帧率，swing更新须切edt，辅以fps监控定位性能瓶颈。
直接继承 Thread 类实现游戏循环，在 Java 中确实简单直观，但帧率容易飘——渲染快了卡顿感弱，慢了就掉帧、输入延迟、物理错位。稳定帧率的关键不是“拼命跑”，而是“精准控时”：让每帧逻辑更新和画面绘制尽量落在目标时间点上，同时应对系统调度抖动和 GC 干扰。
用固定时间步长控制逻辑更新
别让 update() 依赖实际耗时，否则设备一卡、帧一拖，角色就瞬移或穿墙。必须解耦“逻辑步进”和“渲染时机”：
- 设定目标帧率（如 60 FPS），算出理想单帧时长：
long targetNs = 1_000_000_000L / 60; - 每次循环记录起始纳秒时间，执行
processInput()和update(fixedDelta)，其中fixedDelta = 1.0 / 60（单位：秒） - 哪怕某帧实际花了 25ms，逻辑仍只推进 16.67ms，避免累积误差
睡眠补偿 + 防负睡，守住帧间隔底线
Thread.sleep() 是最常用的节流手段，但精度差、易被中断。关键写法要防坑：
- 计算剩余可休眠时间：
long sleepNs = targetNs - (System.nanoTime() - startNs); - 转换为毫秒时向下取整，再用
Math.max(1, ms)避免传入 0 或负数导致sleep(0)变成“让出时间片但不休眠” - 捕获
InterruptedException后建议设标志位退出循环，不要简单忽略
避免主线程阻塞与 Swing/AWT 线程冲突
如果你的 GameThread extends Thread 在 Swing 界面里调用 repaint() 或修改组件，必须走 SwingUtilities.invokeLater()：
- 渲染逻辑本身（如
BufferStrategy.show()）可在游戏线程做 - 但任何涉及
JPanel、JFrame状态变更（如弹窗、得分标签更新）必须切回 EDT - 否则可能死锁或 UI 冻结，表现为“画面不动但控制仍有响应”
加一层帧率监控，问题早发现
光靠肉眼看不出是 58 还是 42 FPS。在循环里埋个简易 FPS 计数器：
- 用
System.currentTimeMillis()每秒统计一次渲染次数 - 打印到控制台或小字显示在角落（用
Graphics.drawString()） - 若持续低于目标值，优先查
render()是否做了耗时操作（如重复加载图片、未缓存 FontMetrics）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
