技术文章

编写此文的目的，并不是教大家如何写出没有Bug的代码。 没有Bug是不可能的。 话虽如此，但是我们完全可以在开发阶段，避免一些低级的Bug。笔者在游戏上线后维护服务器的时间较长，我发现线上所谓的严重问题，真正出问题的代码就是那么几行（一般不会超过10行）。也就是说，这些容易出问题的部分，并不是系统中复杂的部分。因此，我们一定有办法在事前对其进行规避。 我认为避免Bug需要我们有良好的开发习惯，和冷静耐心的心态。于此之上，再通过经验加以一些技巧，就可以避免很多大小Bug了。其中，我认为最重要的是习惯。好的习惯不会让你多花太多时间，但是能尽早发现问题。 习惯和技巧 自测 自测，即代码编写结束后，在本地或开发环境中运行，然后通过白盒或者黑盒的方式测试自己开发的代码。 在本地开发时，务必拥有一个开发环境，这个开发环境可以测试自己正在开发的、还未合并到主干的代码。有了这个环境，你就可以快速地将自己新开发的内容运行起来。如果可以Debug查看每一行的结果就更好了。 自测的意义在于，你可以成为自己代码最早的测试人员，验证自己的思路是否真的被正确开发。自测能给你一个机会，让你执行自己的代码，并且能让以下容易遗漏和犯错的部分得到快速验证： 仔细检查if语句的逻辑判断是否正确 检查玩家数据状态是否正确改变 注销后再登录，即可检查玩家数据是否正确写入 如果你的环境不允许你打断点，或者一些情况比较复杂（多线程环境或有延时函数等），你可以在本地多打一些debug级别的日志，查看数据的处理过程。 Q&A 我等客户端同学开发完，联调的时候再一起测不行吗？ 可以，但是在联调时你的工作重心已经到了其他地方，你会忽略或遗忘当时写这段代码的一些想法。而这些想法很有可能就是容易出错的地方。另外客户端同学一般只会测自己感兴趣或者担心出问题的部分，他们关注的部分不一定和你一致。 要是我都写正确了，自测不就是浪费时间吗？ 不。我们人类一定会犯错，即使我们逻辑写对了，也有可能会把诸如道具产销日志等一些不影响功能，但是运营、策划需要的部分遗漏，也有可能会忘记打warning日志或者error日志，或者是发现一些变量名不合适，或者是重新回看的时候发现代码结构冗余臃肿。这些都是值得修改优化的点。如果我们不自测，那么可能未来就没有时间拿来安排自测了。 服务器开发逻辑的时候，没有现成可用的客户端包进行测试，自测很麻烦。 是的，很麻烦，但是并非毫无办法，接下来会介绍一些自测的技巧。 自测的技巧 对于简单的客户端和服务器交互的接口，可以想办法在客户端手动输入协议号及协议结构，发送指定的协议数据，然后在服务器打Debug断点进行检查。 对于玩家数据经常变化的新功能，可以在数据变化推送的时候打印debug日志，通过日志来确认玩家数据正确性。 对于情况比较复杂的功能，可以先写一些私下用的一次性gm，先模拟复杂的情况，然后再进行目标功能的测试。、 总之，只要你想测到你的功能，在环境允许的情况下，一定有办法测得到。 变量及函数命名技巧 表示某事的次数不要用Times，而是用Count。原因是Times容易和Time混淆，无法一眼区分到底是次数还是时间 表示时间长度不要用Time，而是用Duration。因为“时间”这个概念本身就有歧义，可以表示某个时刻，也可以表示某一段时间。建议用Time甚至Timestamp，TimeMillis，TimeSeconds来具体指代某个时刻的时间戳，用duration来指代时间段。 如果针对某个对象要设置某个属性的值，并且设置时还要对其有特殊逻辑，并且项目中已经装了lombok依赖，则最好不要再命名setXXX()，因为这样会重写lombok的@Setter省略的函数，并且容易让阅读者忽略这个函数内有特殊逻辑。 不要使用setXXX()，但是你可以针对这个业务逻辑，定义一个更贴合业务的逻辑，比如设置玩家积分时，同时更新排行榜上的玩家数据，则setScore()会让人误以为这个函数只是给对象里的score属性赋值，而如果是叫updateScore()或updateScoreAndRank()，则可以直观的知道，这个函数要更新积分，并且可能会更新排行榜。 代码分段 代码一定要分段写。印象中有一些书籍或者公司里的开发规范中约定，每个函数不要超过多少多少行。我想也许是担心大家把函数写得太长，可读性变差而设的规则。但是，我认为真正的问题在于可读性。在某些特定情况下，一些函数可能来不及优化，不得不写得很长，但我们至少可以通过分段和注释，对代码进行梳理。 一个好的代码分段结构，大概如下： //单行注释A：介绍接下来一小段要执行什么内容 aaaaa; bbbbb; if (c) { ddd; ..... } //单行注释B：介绍接下来一小段要执行什么内容 aaaaa; bbbbb; if (c) { ddd; ..... } //... 注意，在两段代码之间，有一个空行。这个空行很重要。他代表着上面这段代码的含义是最上面单行注释A，而下一段代码的含义是单行注释B。如此，阅读者可以很轻松地理解这两段代码到底分别执行了什么逻辑。 分段的技巧 在理清楚需求的业务逻辑后，你可以先写一个空函数，然后再函数内只写注释，不写逻辑。 public void reward() { //判断功能开启 //判断活动开启 //判断玩家传参 //判断玩家领取状态 //扣除玩家消耗 //修改状态 //发放奖励 //推送奖励弹窗 //返回成功给客户端 } 当你把这个函数需要做的事情梳理清除，简单写出注释，分段也是水到渠成的事情了。...

游戏项目公测上线之后，玩家总能找到我们预期之外的方式，做出超乎预料的行为，线上服务器就会有各式各样的错误情况。即使在开发过程中我们已经尽力去编写健壮的代码，完成黑盒白盒测试和代码Review，也无法完全避免线上的各种问题。 不过我们不需要为此悲观。在Java中，底层的虚拟机足够健壮，此外JVM也提供了很多工具给我们进行排查和修复问题。 重载class以修复错误逻辑 在线上服务器中业务逻辑有问题时，我们可以针对出问题的类，在本地修复代码逻辑后，编译出新的.class文件，然后上传到服务器能访问的文件夹目录中，使用Java虚拟机的redefineClasses()方法，将新编译的正确业务逻辑的类class重载到线上的JVM虚拟机中，覆盖之前的class。 如此一来，线上执行的class被替换，后续具体的方法被调用时，执行的是新class的代码业务逻辑。 在线上执行本地编写的代码 使用Groovy脚本，可以在线上服务器中运行代码。在本地编写好groovy脚本代码，通过线上提供的接口（可以是后台接口，或者是GM管理员指令入口）执行groovy脚本内容。 如此一来，当我们对线上服务器的情况有疑惑，需要打印具体的内容；或是希望能修复线上用户的错误数据，就可以使用直接执行脚本代码进行操作。 需要注意的是，Groovy脚本实际上是对使用者要求非常高的一项技术，几乎是线上游戏修改器般、黑魔法般的存在。用得好，可以快速修复玩家数据，能够快速查到服务器异常状态；用得不好，甚至可以直接删库跑路。 关于重载class和执行groovy脚本，代码可参考 https://github.com/jonathanlin768/JavaHotFix 仓库。 策划配表重新加载 有一些在线无感知的游戏热更新是通过策划配表重新加载来实现的。偶尔有一些版本开发过程中，可以先把代码更新到服务器线上，但是不着急马上把新功能开启给玩家，策划可以在功能还未和玩家见面时，修改新功能相关的数值，也可以通过修改活动时间等方式来动态调整功能的开启。 既然策划配表重载可以调整功能的开启，那么必然也可以完成功能的关闭。在开发过程中可以定义一张系统功能表，上面记录各种功能的id，并且有一个强制关闭的标记。开发过程中如果判定功能id关闭，则不允许执行后续逻辑。 如此一来，如果线上已出现异常情况（如新玩法无法正常继续、奖励被刷），则可以快速先关闭具体的功能id，让后来的玩家无法继续造成错误情况。 日志 所有人都知道要打印日志，但是到底打印什么日志最有用的呢？不同的项目有不同的答案。但是打日志是非常有用的，这一点毋庸置疑。 根据我的理解，要打印日志的情况有： 策划配表配错时，打warning。在开发阶段，策划要对自己的表进行测试。他们很有可能填错了数值而不知道。这时候打印出日志可以快速定位到底哪里配错了。 千万不能执行到的错误逻辑，打error。开发过程中如果发现一些情况是异常的，是正常逻辑肯定走不进来的，甚至可能因为异常而导致记录了错误的状态，则一定要打印日志。比如某个玩法一定要组队才能游玩，但是玩家在没组队的情况下请求游玩，说明玩家在之前已有错误，因此需要打印日志以记录情况。 玩家多次反馈出问题的功能逻辑，在最关键处打info。比如某个玩法结束后发奖失败，则需要在发奖的各个阶段打印日志，用以分析哪一个步骤出现问题。 玩家核心玩法行为日志记录，这个可以打info，也可以使用额外的行为日志记录（因为玩家行为可能很多，全部打到log文件会太大，所以可以将其通过消息队列发送到另一个数据仓库中进行汇总分析）。比如MMO游戏的玩家地图跳转，SLG游戏的战斗记录等。 不要打印日志的情况有： 接口的业务逻辑中，已有明确错误提示后返回的情况。如在商店道具购买时道具不足，客户端已能收到有意义的文字错误信息，则再在服务器打印错误日志是意义不大的。 尽量不要在太公用的业务逻辑里打印日志，即使要打印也要加一些条件。这是因为公用逻辑会被各个不同的业务调用，并且一般是主要的玩法。打印日志不加条件限制的话，会造成日志过多而不方便排查。 什么时候用info，warning，error？ 这个问题也是不同的项目有不同的答案。 我的理解是：为了观察玩家和服务器状态的用info，不影响玩家继续游玩，但是确实可能有异常的用warning，要是执行到就一定是有错误的用error。 版本更新前的内部服务器日志一定要关注 当版本开发完毕，到测试阶段时，一定不要觉得测试人员没有反馈就完事大吉了。一定要关注内部服务器的日志，尤其是新打印的日志。内网能看到的日志，外网一定能看到；而外网能看到的日志，内网也一定能复现。 最后，不用担心日志打太多的问题。查不到问题的原因才是更坏的情况。 服务器状态监控 版本更新后，新玩法开启的几天，一定要有意识观察线上服务器的CPU和内存使用状态。就算没有搭grafana那样的工具，你也可以连到线上服务器通过Linux命令查看是否异常。如果CPU过高或者内存不够，则需要尽快把问题反馈出来，从而尽快分析并且处理问题。 这绝对是一个好习惯，原因是有一些问题可能玩家遇到了没反馈出来，他们可能觉得无伤大雅，但是那些没反馈的问题，对服务器的状态也许存在一些风险。 线上问题定位 前文所述内容都是为了避免和修复线上问题。而如何定位线上问题，才是服务器开发中最困难的一环。 这件事的困难之处在于， 无法复现玩家所遇到的情景； 玩家反馈的信息是玩家理解的内容，不一定是服务器上的问题所在 情况是耦合发生的，触发条件苛刻 而当我们花了大量时间排查，最后可能发现只要改不超过10行代码就能解决问题。这或许有一点幽默，但是却是经常发生的情况。 但当我在此回看过去，我发现线上问题一定是能查到结果的，只不过是时间成本问题罢了。真正阻碍我们查到线上问题症结的是我们的内心。 要相信问题是一定能被排查到的 计算机科学是一门年轻的学科。它远没有达到物理学中“电子双缝干涉”那样深奥而暂时无解的情况（当然你一定要拿“比特跳变”这种极端罕见而异常的情况抬杠的话，我就认输）。而游戏服务器的环境配置，都是由你我这样的凡人搭建的。游戏服务器的业务逻辑更是由团队里的大家编写的。所以一切的问题是一定能定位得到的。 而在排查过程中，要相信一点： “所有的问题都会解决的” 当你在排查线上问题的时候，不要惧怕那些线上问题，也不要惧怕那些给你施压的人。程序员常有的完美主义让我们认为一切的代码问题都是可控的，因为业务逻辑是我们一行一行写出来的。但是这不代表代码就一定没有问题。恰恰相反，出问题才是常态。出问题不代表我们不好不优秀，而是“我们还有未知的内容需要去学习”。不要惧怕那些给你施压的人，因为与问题正面对抗的人，就是屏幕前的你。你本应该是伟大而强大的。专注于你要排查的问题，像侦探一样耐心地分析各种蛛丝马迹，所有的问题都会解决的。 分析玩家所述内容，排查异常情况 当玩家反馈错误的情况时，根据玩家的描述定位到具体的玩法，这时不要直接钻到玩法的业务逻辑代码之中，那就如大海捞针了。我们应该根据玩家提供的玩法信息，游玩时间，反过来去查找日志，观察其在出问题的前后执行了什么操作、消耗和获得了什么道具、游玩了其他的什么玩法，在此期间是否有可疑的错误日志等等。 这一步同时你需要去理解玩法的具体内容，比如时间，状态等。通过日志和玩法内容，去勾勒玩家当时的情况。 模拟玩家所遇到的环境 有条件的话，尽量能把出问题的玩家的数据导入到自己的服务器上。这样我们就可以在本地进行各种尝试。如果能把玩家出问题前后的玩家数据拿到本地则更佳。即使没有玩家数据也没关系，在内部环境中模拟玩家所遇到的情况，通过玩家提供的视频，和服务器上的日志，可以得到玩家的状态，进行游玩，也一定会有新的理解。如果实在是无法在本地复现，你也可以用脚本到服务器上执行一些代码，打印玩家现在的状态（现在的状态也是有意义的，玩家有自己的方式再次复现）。 仔细甄别“问题情况”和“猜测的原因” 当线上问题发生时，如果是大问题或者难排查的问题，会有很多人的噪音在耳边叽叽喳喳。他们提供的思路不一定是错的，但是可能和当前最重要的问题没有关系。一定要分析出问题的情况在哪里，专注于要修的问题的情况。会有一些对游戏很了解，但没有看代码的人提出很多猜测，要理性地分辨这些猜测，小心仔细地验证各方论点。 如果真的查不出，就打印排查日志 分析玩家行为、导玩家数据到本地、模拟出问题的环境、并且各方讨论也没有结果，那么请打印好排查日志。 排查日志一般是为了以下目的： 检查关键代码逻辑是否被访问到； 当执行代码逻辑到某一处时，检查玩家的状态是否正确。 因此这样的排查日志，需要打印的细节一定要越丰富越好。如果打印的内容很多，最好能用StringBuilder将多行内容拼成一个String，然后直接用一行log打印出来，以避免日志收集器收录到只言片语。 你甚至可以针对某一个玩家游玩时，仅针对他打印各种细节日志，甚至可以包括程序调用的堆栈信息。

内存泄漏（Memory Leak）通常指的是计算机程序中一种资源管理失当的问题。简单来说，就是程序申请了内存空间，但在不再使用它的时候，没有将其释放，导致这部分内存一直被占用，且无法被程序再次访问或操作系统回收。 为什么会内存泄漏？ 在Java中，当一个对象A拥有另一个对象B的引用时，如果B只有来自A的这一个引用，并且A一直没有释放，则B也不会被释放。因为JVM并不知晓代码的业务逻辑，他只知道B还被其他对象引用，并且A也正在使用之中。因此JVM会认为，B对象还不可以回收。 然而，A对象没有移除到B对象的这个引用，有可能是因为业务逻辑处理不当所致。例如，当A是一个单例的全局对象管理器，管理一系列对象，而B对象恰好在业务逻辑中应该被回收，而没有回收时，B会一直存在于A的引用中。此时B就无法进入正常的回收逻辑中了。 如何避免内存泄漏 在任何时刻，创建对象时，都要思考一下生命周期。 可以试着问问自己：目前的这个对象被创建后，它应该在什么时候被销毁？是这个函数结束时、副本玩法结束时、组队结束时、玩家下线时、还是一直到服务器停止后？ 考虑不使用引用，而使用id等基础数据类型进行关联 这个对象创建之后，要离开创建它的函数，就一定要被其他对象管理。在管理器之外，还会被其他对象引用吗？如果是，那么要考虑其引用什么时候结束。或者，如果管理器能提供唯一的id进行管理，那么在其他对象上就存储一个唯一的id，在需要时再通过id向管理器查询出对象，在函数调用栈中使用，随着函数结束后栈帧弹出回收。 在外部补充业务逻辑，检查内存泄漏 如果业务足够复杂，系统陈旧，无法进行彻底排查泄露的位置，可以考虑每隔一段时间检查内存中是否有内存泄漏，然后强行将其清除。相当于是在业务层执行一次垃圾回收行为。 定义过期时间，限制使用条件 如果业务复杂，可以考虑在对象使用时加一个过期时间，超过时间还被访问，则执行清理。

前言 在多年的游戏服务器开发工作中，在大多数时候，开发内容仅仅是将策划的需求“翻译”成服务器程序代码。但是这份工作需要的严谨程度非常高，远远不止将需求实现而已。 有一些内容是开发过程中就需要有意识去注意的。如：必须校验客户端传参；先扣除道具，再改状态，最后发奖励以保证防止玩家刷奖励等。做到这一步，基本上能保证客户端的行为能在服务器的控制以内。 但还有一些内容，是由于项目长期开发过程中，多个需求互相杂糅导致的问题。比如今天的功能可能和去年年初的功能耦合，但是触发条件比较苛刻，埋得比较深。这种问题一般不会是什么影响服务器启动的大问题，但是很有可能会造成业务逻辑的漏洞。面对这种问题，我们是比较难在开发中能提前预知，一般是靠人力测试或者接口压力测试的时候查看报错日志来发现。 还有一些是需求过于复杂，变动太大，程序跟不上策划思路。这种情况其实更考验沟通能力，准确来说，是发现策划“核心需求”的能力。策划想要的东西可能和他说的内容并不一致，他想要的需求也和他真正告诉你的不一致。所以这就要求我们的代码能够支持一定的灵活性，能够提前预判策划真正想要的目标效果。当然这也需要我们程序员多玩不同类型的游戏，从而尽可能让思路和策划在同一水平面上。 本系列是本人在多年游戏服务器开发过程中，积累了些许经验，闲暇时总结在此处。 道具防刷 网络游戏最担心的事情，除了服务器崩溃之外，就是道具被玩家无限重复获得，俗称“刷奖励”。在大多数情况下，发放道具都是非常基础的功能。一般发放道具这一步不会有什么太大问题，问题主要会出现在发放道具前的业务逻辑校验。 如果校验的条件覆盖面不足，当玩家没有付出足够代价的情况下，获得了道具，会大大影响服务器内的经济系统。好比有人发现能去商店“零元购”而不被制裁，那就没有人愿意劳动了。 防刷原则：校验条件 -> 扣消耗 -> 改状态 -> 发奖励 无论什么情况，都务必遵循此条件：校验条件 -> 扣消耗 -> 改状态 -> 发奖励。 一般来说，校验条件放最前面没有异议，但是扣消耗、改状态、发奖励却不一定大家都会认同。在有事务和锁的情况下，完全可以做到开启事务后，对核心对象上锁，校验好消耗和奖励，然后一并提交。但是对于游戏服务器来说，消耗和奖励是允许一定程度的误差的（因为可以后期补发、扣除等操作）并且服务器性能的优先级高于消耗和奖励的优先级。如果每次玩家去游戏商城进行道具购买，或者挑战关卡通关都要有事务和锁的开销，会大大影响效率。 因此在没有事务和锁的情况下，扣消耗、改状态、发奖励这三个步骤中，我们优先要让玩家吃亏，必须先扣除消耗。然后再修改状态，让下一次请求来临时校验新的条件。最后再发放奖励。 补救措施：完善的资源道具产销日志 玩家在游戏中的每一笔消耗和获得，都需要记录下来。除了玩家信息、道具信息、变更数量等一定要记录的内容之外，还至少包含以下内容：日志枚举（数字，用于数据库中创建索引），产销细节（提供一个字符串，记录本次产销相关的事件，关联的id，如通关的副本id、购买的商品id等）。如此一来，即使真的存在被刷道具的情况，也能快速定位到被刷的数量。 这个日志最好能不要删除。这里就可以考虑使用大数据相关的数据库来存储这种大量结构化数据了。 事前预防：最重要的是把状态改对 被刷道具的原因基本上都是状态没有正确更改。大部分情况下，用心的开发人员会记得修改状态。 但是还会有一种比较隐秘的Bug情况：修改的状态可能并不是这个业务需要的状态。这种情况最容易发生在复制其他功能的代码到自己的功能，然后删改细节的时候不小心遗漏。 事前预防：填写正确的产销日志信息 另外，道具产销的日志也一定要认真检查填写的日志信息。这一部分是非常容易忽略的。因为即使代码进行了自测，道具正常扣除与增加，也无法直观地看到日志里的内容。 事前预防：任何一行代码，有条件都要自测 没有人比你懂你的代码，哪怕是用心Review你代码的领导。所以千万不要有侥幸心理，有条件自测就多点一下，能断点走一遍看看就走一遍。这个过程并不会花费太多时间。但是却能很快让你看到代码中的缺漏。

最近在Bilibili刷到了一个视频，是一个38岁老程序员找不到工作后，发了个视频发发牢骚。视频链接。看了之后很有感慨，因为我自己在2023年也经历了总计4个多月的失业时光。在那段时间的自我怀疑让我印象深刻。不过本文并不是在此忆苦思甜，而是借由此视频，探讨35岁是否真的是软件开发人员的终点，软件人是否真的到了35岁就必须“退役”，找不到工作或者转行。 ...