最近做有关于游戏服务器用单线程的好还是多线程的好的讨论有同学问：服务端逻辑全单线程的模型，为了避免查询离线玩家数据造成阻塞，除了启动服务器全部加载以外还有更好的办法吗？同学B：单线程逻辑模型也属于很常用。逻辑本身不容易出问题。IO得全部分出去。同学B：用异步加载事件。数据加载完成后。再重新把任务排入单线程任务队列。同学C：各种活动NPC打完就要从场景消失 战斗线程和场景线程分不开同学C：场景线程依赖战斗的结果同学C：战斗的结果会影响NPC在场景的动态显示同学C：然后还有交易，还是和端游一样的在线即时交易同学C：用多线程就容易刷物品同学C：用多线程就容易刷物品同学C：我最开始想的是 交易的时候将交易的物品放到第三方线程去搞，但是如果玩家中途点了取消或者下线或者各种状态 你要将道具返还给玩家同学C：但是在这期间 玩家可能又会操作背包同学D：交易的时候 被交易的东西是锁住的同学C：你说的被锁住的 是个什么概念，是不能进行其他任何操作吗同学E：交易的时候可以不用锁。做线程排队同学B: 我们以前的交易是和WOW完全一样的 放上去的东西 交易成功/失败前 在背包里面不能移动、丢弃然后玩家一方点击移动 也马上取消整个交易 同学E：掉取消 也 让他进入线程排队啊同学B:回滚没必要思考那么复杂可以设计交易成功之前都是副本操作专门用一个交易容器来存交易过程中的这些临时对象、状态同学F：涉及到多玩家的交互要么加锁，要么抛到各自的线程处理，然后用回调。比如我买你的东西，在我这里扣了钱之后，就发个请求到你的线程扣除物品，扣除结果再回调我这边。决定是失败返回扣的钱给我，还是成功给我加物品。这种效率是最高的，，不用锁。同学C：我说的交易不是摆摊同学B：这种架构会搞死程序员，这么做完了 后面维护期也户i被搞死同学M：你们怎么区分的单线程还是多线程想改为单线程 就不用考虑阻塞了同学B：接收请求多线程处理按逻辑分到不同队列后单线程某些特定场景、活动再单开线程总之就是接收多线程 处理逻辑单线程 偶尔有多线程的地方自己维护锁 然后用了OrderedThreadPoolExecutor
多对自己说“我能行，我一定可以”，
