版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/littleschemer/article/details/72803495
游戏服务端承担着游戏复杂业务逻辑实现，玩家数据持久化等重要作用。作为一个合格的服务端业务狗，我们有必要遵守一些好的防御手段，让自己的代码少踩些坑，或者当出现了bug，能够在第一时间进行抢救。
下边一些开发原则是我的经验总结，欢迎补充，不喜轻喷o(^_^)o
- 检查玩家请求数据的有效性
不管是做web后端，还是游戏后端开发，我们都要检查客户端请求数据的有效性。举个栗子，假设玩家在商店买了一个道具XX，数量为100。对于上传到服务端的参数，例如所购买的道具id和购买数量，我们需要重点检查购买数量参数。总不能玩家说要买100个，但是玩家的金币只能购买10个，服务端就傻傻地给了玩家100个道具吧！
有经验的程序员总是不厌其烦地告诉新手程序员，必须对传入函数的参数进行有效性检测。类似地，我们也必须对玩家的各种请求参数进行检测。很多外挂工具可以直接模拟游戏上一次发包内容，甚至通过对数据的分析进行参数篡改。所以，我们对于直接处理用户请求消息的逻辑方法，应该进行相关有效性检查。
- 重视行为日志
策划童鞋的脑洞很活跃，有时一些业务流程性非常强，要达到目标往往需要多个步骤有序地完成。我们做开发的，在面对一些强流程性或者数据比较重要的逻辑，一定不要吝啬留下行为日志。打多点日志，出了问题，即使测试人员无法重现，我们也可以根据日志以及代码逻辑发现问题。
当然，打日志也是有技巧的。由于日志是给开发人员自己调试排错的，我们没必要像写作文一样下笔有神，我们只要打印一些关键的行为字眼以及相关参数值。对于同一个模块，我们最好采用相同的前缀作为关键字。这样，当需要查询的时候，只要输入模块前缀以及玩家id，就能清晰地查看完整的流程行为。
- 合理使用锁
java的线程同步机制主要靠锁。不合理地使用锁，容易引起死锁。如果出现死锁，一般需要重启服务。如果你把服务搞垮了，就准备扣绩效吧。我们可以通过一些保守的策略，尽量减少发生死锁的可能。
一些比较好的方法有如下：
尽可能使用有超时中断的锁，例如ReentrantLock.tryLock()方法。
尽量避免锁里有锁，有时我们为了细化锁的粒度，采用了在一个锁变量里面再使用另外一个锁变量，这种情况最容易发生死锁了。我们可以直接在最外层代码用一个大锁代替里面多个小锁。有时，为了代码更可控，宁可牺牲一些性能。
- 在别人的方法里加逻辑，请用try.catch()进行包装
游戏业务其实就是功能的堆砌和业务的修改。很多时候，我们经常需要在别人的模块里面加上自己的业务。这个时候，别忘了将自己的代码写在try.catch里面。这样可以保证，当我们的代码发生异常，不会打断已有的逻辑。
- 不要在循环内部向客户端推送消息
由于客房端在每一帧拆包的数量是有限的，如果在循环体内向客房端下发消息，会导致客户端拆包速度处理不过来，造成卡顿效果。如果确定需要在循环体内处理业务逻辑，可以把每一次迭代的中间结果收集起来，最后统一发下去。
- 给自己的功能加个开关
在实现一些自己没什么把握的功能，我们可以在这些模块加个对应的功能开关。这些开关其实就是一个简单的布尔变量，当变量为false的时候，我们就不让代码继续往下跑了，同时告诉玩家，该功能暂时关闭。至于怎么切换开关，可以使用管理工具或修改内存的脚本。
- 有实现热更新代码的机制
不管是多牛逼的程序员，只要是代码，就有可能出现bug。我们更关心的是，当真的出现bug的时候，能够在不重启服务器的情况下，进行代码修复。代码热更新是一个大的话题，有很多机制可以实现，在这里就不展开了。有兴趣的同学可以参考我一篇文章->手游服务端代码热部署