我正在开发射击游戏，我正计划用实体（子弹，怪物等）充斥屏幕。我已经尝试了一个全局计时器来更新屏幕上的所有内容，但是当我像我想要的那样泛滥屏幕时，我已经得到了一些严重的fps下降。
所以，我认为自己有两种选择。我可以为每个单独的实体提供一个计时器线程，或者我可以将该级别分成块，并为每个块提供自己的计时器。
对于第一个场景，实体有自己的计时器线程，我最终会有数百个实体，每个实体都有自己的线程运行一个计时器。
在section选项中，我将使用一个计时器的多个部分同时更新多个实体，并检测实体何时从一个部分离开到另一个部分。
我不熟悉编程与内存效率，所以哪种方法更适合我使用？
答案 0 :(得分：0)
您可以尝试ScheduledExecutorService。
这是Java higher-level concurrency API的一部分。您可以决定应该存在多少线程（它为不同的任务重用线程以避免每次创建新线程的开销，因此预期比始终创建新线程更有效）或使用缓存线程池（这将创建尽可能多的线程，但是一旦Thread死了，它将重新使用它来运行新任务。）
此API的另一个优点是，您不仅可以运行Runnables，还可以使用Callables，它可能会返回一个值供您将来使用（因此您可以在不同的线程中执行计算，然后使用结果每个线程的最终结果）。
答案 1 :(得分：0)
我正在尝试类似的东西而且没有明确的答案。但是，我从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
他们正在讨论超线程和Actors的acca框架等问题。