首先得说，你这个观察真的挺反直觉——按常理说FPS上限设得低，应该给渲染留更多缓冲时间，结果反而字符绘制耗时更长。我之前做AWT小游戏开发时也碰到过类似的情况，当时懵了好一阵，结合你的测试代码和结果，大概是这几个底层机制在起作用：

1. 垂直同步（VSync）与BufferStrategy的同步交互是核心 #

你的显示器是60Hz的，这一点是关键变量：

• 当TARGET_FPS设为60时，bufferStrategy.show()会主动等待显示器的垂直同步信号（多数系统默认开启VSync，Linux下甚至可能强制绑定显示器刷新率）。这时候整个渲染线程会被挂起，直到下一个VSync信号到来。
• 而设为120时，因为显示器只能输出60帧，show()不需要等待完整的VSync周期（或者系统允许画面撕裂输出），线程休眠时间极短甚至无需休眠。

这种等待会带来两个隐性开销：

• 字形缓存（Glyph Cache）失效：Graphics2D会预渲染常用字符的字形位图存到GPU/CPU缓存里，当线程因VSync挂起时，这些临时缓存可能被系统释放或标记为可回收。下次渲染时需要重新生成字形位图，直接拉高了drawChars的耗时。
• 显存缓冲区复用率下降：三重缓冲在同步VSync时，每个缓冲区的使用间隔刚好是16.6ms（60FPS帧时间），间隔太长会导致显存中的缓冲区数据被系统回收，下次绘制需要重新初始化缓冲区，增加了额外成本。

你看Linux下的差异特别明显——60FPS时drawChars耗时是120FPS的2.6倍，大概率是Linux的AWT后端（比如X11）对VSync的同步更严格，缓存失效的影响被放大了。

2. 线程休眠导致的CPU/GPU缓存“变冷” #

你的代码里，低FPS上限对应的sleepTime更长（比如60FPS时，若渲染只用了2ms，就要睡14ms左右）：

• 线程进入休眠后，CPU会把这个线程的缓存页（比如字体数据、绘制临时变量）换出到主存，甚至被其他进程占用。当线程被唤醒时，需要重新加载这些缓存，导致drawChars的实际执行时间变长。
• 高FPS上限时，线程休眠时间极短（甚至不需要休眠），CPU的L1/L2缓存一直保持“热”状态，字体渲染的相关数据始终在高速缓存里，自然绘制更快。

你可以做个小测试：注释掉代码里的Thread.sleep逻辑，让帧率跑满，不管设60还是120，drawChars的耗时应该会趋于一致——这就能验证是不是休眠导致的缓存变冷问题。

3. Graphics2D批处理策略与帧率的关联 #

Graphics2D本身会对连续绘制操作做批处理优化（比如把多个drawChars合并成一个GPU命令），但这个批处理的缓存有效期和线程活跃性强相关：

• 当线程间隔很久才做一次绘制（低FPS上限），批处理的内部缓存会被AWT的垃圾回收机制清理，下次绘制需要重新构建批处理命令，增加了额外开销。
• 高帧率时，绘制操作频繁，批处理缓存一直被复用，GPU能持续高效执行命令，耗时自然更低。

验证与优化建议 #

给你几个快速验证的小方法：

1. 禁用VSync测试：在显卡控制面板关掉垂直同步（比如N卡的“管理3D设置”→“垂直同步”设为“关”），再跑60FPS测试，看drawChars耗时是否下降到接近120FPS的水平。
2. 预渲染字符缓存：提前把所有需要的字符渲染到一个BufferedImage里，每次渲染时直接画这个Image而不是调用drawChars。这样不管帧率上限多少，耗时都会稳定——因为字形缓存被提前固化到Image里了。
3. 去掉休眠逻辑：注释掉Thread.sleep部分，让帧率不受限，对比不同TARGET_FPS下的耗时，排除线程休眠的影响。

总结下来，这个问题不是你的代码有问题，而是AWT的底层渲染机制、系统线程调度、显卡驱动策略共同作用的结果。在AWT这种偏老旧的渲染框架里，这种平台相关的性能差异其实挺常见的～