在游戏服务器中，线程管理是重中之重，因为线程的数量不能太多，所以为了提高游戏服务器的并发性，就是必须提高线程处理业务的速度快，线程不能长时间卡顿，比如不能有网络io、磁盘IO等耗时操作。所以我们将有限数量的线程分配成按需分配。线程的主要分配方式如下：1、带客户端的IO线程，负责接收客户端消息和向客户端发送消息。2、处理播放器业务的逻辑线程，负责业务逻辑的处理和计算。3、处理rpc或数据库同步的网络线程。负责不同服务之间的通信4.处理日志的磁盘IO线程对应的线程自己做时间。但是这时候，问题就来了。由于这些线程是按用途分配的，不同线程之间的数据交互不会无缘无故发生。比如玩家登录和排队等，如果一个区域有一台物理机，1个IO线程处理和client，16个业务逻辑线程，3个线程请求数据库。其他人首先被忽略。这时候服务端收到客户端的登录请求，业务线程收到这个请求。首先要做的是查看数据库中的用户信息，因为业务逻辑线程是多个用户共享的，所以这里不能做。等待数据库请求返回，否则会卡在其他业务逻辑处理中。最好的办法就是把这个请求封装成一个事件，交给数据库同步线程去处理。等待数据库线程处理完，然后把结果告诉业务逻辑线程，再处理业务。这时候处理的数据在内存中，所以速度很快，处理完再返回给客户端。有人说，这不是刷卡登录吗？是的，肯定是刷卡登录，因为处理数据库的线程只有3个。mysql的查询性能测试如下：我们三个线程按1500计算，那么只有登录并发达到1500时，才会感觉服务变慢（实际情况可能更低），如果并发能达到这么高，说明游戏很火爆，可以等着数钱。如果人多的话，我们可以使用排队功能。可以查询数据库线程中等待执行的任务数。如果达到一定值，可以在业务服务中将排队的任务返回给客户端，让客户端稍后再请求。回到正题，游戏服务器线程之间如何传递数据，可能每个人的做法不一样，这里只是其中一种，希望能给大家带来一些参考，算是一种交流和学习。如果你有更好的方法，欢迎评论分享。Java中，多线程之间交换数据，即线程A向线程B发送请求事件，线程A还需要获取线程B的执行结果，比如登录，请求数据库线程查数据库，检查完再告诉逻辑线程。Java提供了Future/Callable机制。详细的可以自行百度他们的用法，但是他们有一个缺点，就是线程A在获取结果的时候是同步的（调用future.get()）。如果线程B没有执行完，线程A仍然会卡住。这个显示不是我们想要的。为此，我们伟大的异步框架netty的作者给出了一个解决方案，就是Future/promise模式。其源码这里暂且不分析。如果你有时间，再写一篇文章解释它。感兴趣的同学可以自行查看。这里只说说它的用法。这段代码只是模拟，实际应用中需要自己设计。首先是数据库查询管理类，然后是业务管理类：通过本例可以实现多线程交互数据相关的其他功能。
