嘿，这个问题我太熟了——完全可以在单线程/循环里搞定固定TPS更新和可变FPS渲染，还能彻底解决你之前多线程遇到的闪烁问题！毕竟你用的BufferStrategy，本来就是为单线程下的双缓冲渲染设计的嘛。

核心思路：固定步长更新，渲染追帧率 #

你的需求是TPS固定64（即每15.625ms执行一次游戏逻辑更新），FPS由玩家自定义。单线程方案的关键是把更新逻辑和渲染逻辑串行执行，严格保证更新的固定频率，渲染则尽可能跟上玩家设置的帧率（硬件跟不上时自动降帧）。这种方式从根源上避免了多线程下更新与渲染的时序冲突——之前的闪烁大概率是因为两个线程同时操作游戏状态或缓冲，导致画面撕裂或部分状态未更新完成就被渲染。

具体实现步骤 #

我给你捋个清晰的执行流程，附一段伪代码参考：

1. 初始化高精度计时变量：用System.nanoTime()（比currentTimeMillis精度高很多，适合游戏计时）记录上次更新和渲染的时间点。
2. 固定步长更新逻辑：每次循环先检查是否到了更新时间，如果累计时间差超过一个tick的间隔（1000/64≈15.625ms），就执行一次游戏更新，并且把上次更新时间累加间隔值（不是直接设为当前时间，避免丢帧）。如果某次渲染卡了导致时间差超过多个tick间隔，要循环执行多次更新，保证逻辑进度不落后。
3. 可变帧率渲染逻辑：检查是否到了渲染时间（根据玩家设置的FPS计算间隔），如果到了就用BufferStrategy完成绘制，然后更新上次渲染时间。
4. 轻量休眠降CPU占用：如果当前既不需要更新也不需要渲染，让线程休眠1ms，避免空转占用过高CPU。

示例代码（Java环境，适配BufferStrategy） #

// 初始化计时变量
long lastTickTime = System.nanoTime();
long lastRenderTime = System.nanoTime();
final long TICK_INTERVAL = 1000000000 / 64; // 64TPS对应的纳秒间隔
int targetFPS = 60; // 玩家可随时修改这个值
long renderInterval = 1000000000 / targetFPS;

// 主循环
while (gameRunning) {
    long now = System.nanoTime();

    // 处理固定步长的游戏更新
    while (now - lastTickTime >= TICK_INTERVAL) {
        updateGameState(); // 你的游戏逻辑：移动、碰撞、AI等，只改状态不绘制
        lastTickTime += TICK_INTERVAL;
    }

    // 处理可变帧率的渲染
    if (now - lastRenderTime >= renderInterval) {
        // 使用BufferStrategy正确绘制
        BufferStrategy bs = getBufferStrategy();
        Graphics g = bs.getDrawGraphics();
        
        // 清空画布、绘制所有游戏元素
        g.setColor(Color.BLACK);
        g.fillRect(0, 0, getWidth(), getHeight());
        drawGameElements(g); // 读取当前游戏状态进行绘制
        
        g.dispose();
        bs.show(); // 交换缓冲，把后台绘制的内容展示到前台
        
        lastRenderTime = now;
        // 如果玩家修改了目标FPS，实时更新渲染间隔
        renderInterval = 1000000000 / targetFPS;
    }

    // 短暂休眠，降低CPU使用率
    try {
        Thread.sleep(1);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}

关键注意事项 #

• 更新与渲染严格分离：更新逻辑只修改游戏状态（比如玩家位置、怪物血量），渲染逻辑只读取状态进行绘制，绝对不能在渲染里改状态，也不能在更新里做绘制操作。单线程串行执行的前提下，这样能保证渲染时的状态是完全稳定的，不会出现半更半绘的情况。
• BufferStrategy的正确用法：每次绘制要先获取Graphics对象，绘制完成后必须dispose()释放资源，再调用show()交换缓冲——这一步是原子性的，能避免画面闪烁。
• 玩家可调FPS的处理：允许玩家修改targetFPS后，要实时重新计算renderInterval，渲染逻辑会自动适应新的帧率。如果硬件达不到目标帧率，渲染会自动跳过一些帧，保证更新逻辑不受影响（游戏速度不会变慢）。

这种单线程方案不仅能解决你之前的闪烁问题，还比多线程简单太多——不用处理复杂的同步锁、线程安全问题，时序完全可控，游戏逻辑的稳定性也更高。

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