我正在开发射击游戏，我计划用实体（子弹、暴徒等）充斥屏幕。我尝试了一个全局计时器来更新屏幕上的所有内容，但是当我按照我的意愿淹没屏幕时，我的 fps 下降了一些。
所以，我认为自己有两个选择。我可以给每个单独的实体一个计时器线程，或者我可以将关卡分成块并给每个块自己的计时器。
对于第一个场景，实体有自己的计时器线程，我最终会得到数百个实体，每个实体都有自己的线程运行计时器。
在部分选项中，我将拥有地图的多个部分，并带有一个计时器一次更新多个实体，并检测实体何时从一个部分离开到另一个部分。
我不熟悉考虑内存效率的编程，那么哪种方法更适合我使用？
我正在尝试类似的东西，但没有明确的答案。但也许我从 Java-Gaming.org 获得的一些反馈会有所帮助或感兴趣。
我尝试的是：每个实体都有自己的线程，并且通过非常详细的屏幕地图（基本上是屏幕的第二个版本）来处理冲突。然后，我有另一个线程来处理屏幕的显示。
一个“早期”版本，有超过 500 个动画实体，在线： http ://hexara.com/pond.html
后来的版本使用了更精细的形状和边界（而不是让实体在边缘死亡和冻结）和碰撞逻辑，例如相互反弹和重力。我也在玩精灵方面的东西，比如“萤火虫”闪烁。我在网页上提到了“演员”，但严格来说，代码并非如此。
java-gaming.org 上的一些人强烈认为拥有这么多线程效率不高。他们有很多有趣的反馈，您可能有兴趣探索。我还没有时间。 http://www.java-gaming.org/topics/multi-threading-and-collision-detection/25967/view.html
他们正在讨论诸如超线程和 Actor 的 acca 框架之类的事情。
您可以尝试ScheduledExecutorService。
它是Java 高级并发 API的一部分。您可以决定应该存在多少线程（它为不同的任务重复使用线程以避免每次创建新线程的开销，因此预计比一直创建新线程更有效）或使用缓存线程池（这将创建尽可能多的线程，但一旦线程死亡，它将重新使用它来运行新任务）。
这个 API 的另一个好处是，你不仅可以运行 Runnables，还可以使用 Callables，它可能会返回一个值，供你以后使用（这样你就可以在不同的 Thread 中进行计算，然后将每个 Thread 的结果用于最终结果）。