问题描述
我正在编写多人游戏的服务器端网络。该游戏是一款RPG，它拥有2000名玩家的绝对最大容量，但它实际上最多可以达到300名玩家，尽管它可能更高或更低。在最长的时间内，每次我必须在很多客户端进行网络连接时，我都坚持使用NIO，因为它不需要使用数百个线程。最近，我遇到了一个PowerPoint演示文稿，其中详细描述了这两个模型，它几乎使得每个客户端的模型看起来优于NIO。我还找到了一些地方，它表明老IO实际上也可以胜过NIO。
I am writing the server-side networking of a multiplayer game. The game is an RPG and it has the absolute maximum capacity of 2000 players, but it practically will max out at about 300 players, although it may be higher or lower. For the longest time, every time I had to do networking where it involved lots of clients, I have stuck to NIO because it did not require the use of hundreds of threads. Recently, I ran into a PowerPoint presentation where it described the two models in detail, and it almost made the thread-per-client model seem superior to NIO. I have also found places where it states that old IO can actually outperform NIO as well.
PowerPoint可以在这里找到（它有点旧）：。
The PowerPoint can be found here (it is a bit old): http://www.mailinator.com/tymaPaulMultithreaded.pdf.
我还没有写任何内容，所以如果我不得不改变整个网络设计，那么从一开始就不会有问题。我没有时间压力。最初，我正在使用NIO设计反应器模式实现（选择一个事件，调度一个处理事件的处理程序）。
I have not written any content yet, so it would not be a problem for me to start at the beginning if I had to change my entire networking design. I am not pressured for time. Initially, I was designing a reactor pattern implementation with NIO (select an event, dispatch a handler to handle the event).
可在此处找到更多信息：
More information can be found here: http://en.wikipedia.org/wiki/Reactor_pattern
我的整个reactor实现旨在使用单个线程。由于我读到旧的IO可以超越，它实际上让我处于两难境地。我不想设计一个复杂的NIO系统，只使用多个线程来充分利用所有的CPU能力，但我也畏惧让一个应用程序使用300多个线程的想法。哪种设计适合我的目的？每个客户端的线程优势在于它真正使用了所有CPU功能本质上，但同时，它使系统陷入困境。更不用说，单个线程的堆栈大小占用了大量内存（乘以几百倍）。我应该坚持反应堆模式吗？
My entire reactor implementation is designed to use a single thread. Since I read that old IO can outperform, it actually put me in a dilemma. 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? The advantage of thread per client is that it truly uses harnesses all of the CPU power by nature, but at the same time, it bogs down the system. Not to mention, the stack size of a single thread takes up a lot of memory (when multiplied by a couple hundred times). Should I stick to the reactor pattern?
我知道这个问题有点含糊不清，但我觉得我需要专门针对我的情况提问，因为我不能在这个网站上找到一个问题，也没有一个网站，它解决了我的问题。有一个关于一个游戏，但该游戏旨在处理成千上万的玩家。
I know this question is a bit ambiguous, but I feel that I need to ask a question specifically for my situation because I could not find a question on this site nor a website where it addresses an issue of my sort. There was one about a game, but the game was meant to handle tens of thousands of players.
非常感谢！如果您需要任何澄清，请询问！
Thanks a lot! If you need any clarification, please ask!
推荐答案
我们的JVM连续运行500多个线程（现在它们位于~700），其中1000个峰值。我认为没有理由认为800线程在某种程度上畏缩值得。当你达到10,000个线程（作为球场号码）时我会开始担心 - 如果你在32位以下运行，可能会更少。当你进入1000s时，你肯定会分配更多的内存，但是1k线程以下的任何东西都不应该是个问题。这是的好页面。
Our JVMs run with a lot more that 500 threads continually (right now they are sitting at ~700) with peaks in the 1000s. I see no reason to think that 800 threads is in some way "cringe" worthy. I'd start to worry when you reach 10,000 threads (as a ball park number) -- maybe less if you are running under 32bit. You certainly are going to have to allocate more memory as you get into the 1000s but anything under 1k threads should not be a problem. Here's a good page on thread creation numbers.
当您拥有大量数量的连接且不经常使用IO时，NIO效率最高。它解决了很多问题，当谈到异步通信时，你可以用NIO做的事情，老IO从功能的角度来看不能做（例如可中断通道和非阻塞IO）但单线程处理程序是一个更简单的模型，我并不惊讶它在许多配置中可以胜过NIO实现。使用NIO，您在Java代码中执行了大量操作，这些操作是在JVM中为您完成的，甚至是在本机代码中为您完成的。流的多路复用和就绪IO的处理都是免费（就复杂性而言）使用旧IO模型获得的所有东西。
NIO is most efficient when you have a large number of connections with infrequent IO. It solves a lot of problems when it comes to asynchronous communication and there are things you can do with NIO that the "old IO" cannot do from a functional standpoint (interruptible channels and non-blocking IO for example) but the single thread handler is a much simpler model and I'm not surprised that it can outperform NIO implementations in many configurations. With NIO you are doing a lot of operations in Java code that are done for you in the JVM or even the kernel in native code. Multiplexing of streams and handling of ready IO are all things that you get "for free" (in terms of complexity) with the "old IO" model.
我会保留它非常简单，坚持每个客户端的模式，直到你有充分的理由去解决复杂性问题。
I would keep it simple and stick with the thread-per-client pattern until you have good reason to take the complexity hit.
这篇关于每个客户端模型或NIO反应器模式的旧I / O线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！