java - 每个客户端模型或 NIO react 器模式的旧 I/O 线程？

Question

我正在编写多人游戏的服务器端网络。该游戏是一款角色扮演游戏，它的绝对最大容量为 2000 名玩家，但实际上最多可容纳 300 名玩家，尽管可能更高或更低。在最长的时间里，每次我不得不在涉及大量客户端的情况下进行联网时，我都会坚持使用 NIO，因为它不需要使用数百个线程。最近，我看到了一份 PowerPoint 演示文稿，其中详细描述了这两种模型，它几乎让每个客户端线程模型看起来优于 NIO。我还发现一些地方指出旧 IO 实际上也可以胜过 NIO。

PowerPoint 可以在这里找到(有点旧):http://www.mailinator.com/tymaPaulMultithreaded.pdf .

我还没有写任何内容，所以如果我必须改变我的整个网络设计，我从头开始也不是问题。我没有时间压力。最初，我正在设计一个带有 NIO 的 react 器模式实现(选择一个事件，分派(dispatch)一个处理程序来处理该事件)。

可在此处找到更多信息:http://en.wikipedia.org/wiki/Reactor_pattern

我的整个 react 堆实现设计为使用单线程。自从我读到旧的 IO 可以跑赢大盘，这实际上让我进退两难。我不想设计一个复杂的 NIO 系统，它使用多个线程来充分利用所有 CPU 的能力，但我也对让单个应用程序使用 300 多个线程的想法感到畏缩。哪种设计适合我的目的？每个客户端线程的优势在于它真正利用了所有 CPU 的自然能力，但与此同时，它会使系统陷入困境。更不用说，单个线程的堆栈大小会占用大量内存(乘以几百倍)。我应该坚持 react 器模式吗？

我知道这个问题有点模棱两可，但我觉得我需要针对我的情况提出一个问题，因为我在这个网站上找不到问题，也找不到解决我这类问题的网站。有一个是关于游戏的，但该游戏旨在处理数万名玩家。

非常感谢!如果您需要任何说明，请询问!

Answer 1

I do not want to design a complicated NIO system that uses multiple threads just to take full advantage of all the CPU power, but I also cringe at the idea of having a single application use 300+ threads. Which design is right for my purpose?

我们的 JVM 持续运行超过 500 个线程(目前大约为 700 个)，峰值达到 1000 个。我看不出有什么理由认为 800 个线程在某种程度上是值得“畏缩”的。当您达到 10,000 个线程(作为一个大概数字)时，我会开始担心——如果您在 32 位下运行，可能会更少。当您进入 1000 年代时，您当然将不得不分配更多内存，但任何低于 1k 线程的东西都不应该成为问题。这是一个很好的页面 thread creation numbers .

当您有大量连接且 IO 不频繁时，NIO 效率最高。当涉及异步通信时，它解决了很多问题，并且从功能的角度来看，“旧 IO”无法使用 NIO 做一些事情(例如可中断 channel 和非阻塞 IO)，但单线程处理程序是一个更简单的模型，我并不惊讶它可以在许多配置中胜过 NIO 实现。使用 NIO，您可以在 Java 代码中执行许多操作，而这些操作是在 JVM 甚至内核中以 native 代码为您完成的。流的多路复用和就绪 IO 的处理都是您使用“旧 IO”模型“免费”(就复杂性而言)获得的东西。

我会保持简单并坚持每个客户端线程模式，直到您有充分的理由接受复杂性的打击。