内存泄漏（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岁就必须“退役”，找不到工作或者转行。 ...

前阵子我参加了一个用爱发电的独立游戏项目，是由一批网友聚集起来想要复刻某三国单机游戏的团队。“用爱发电”，即不获取酬劳，为了自己的梦想去努力奋斗。从24年2月4日开始得知这个组，2月7日进组，到4月4日离开，共经历了两个月。 我不想过多讨论这个游戏开发组中遇到的问题，因为在这个组的问题有其特殊性，并不具有普遍性。我想探讨的是个人开发者面对用爱发电项目时需要注意的内容，和一些心得体会。 ...

摘自某百科：《魏略》蜀军大将魏延认为，长安守将夏侯楙年少，娇生惯养、怯而无谋。今日假若我魏延领精兵五千，背负粮草五千，直由山道深入，寻秦岭而向东，到达子午再往北行。不过十日就能抵达长安。夏侯楙见我军突然出现，必然乘船而逃。如此一来，长安城内只剩下御史、京兆太守而已。长安北门有散民之谷，足以供应我军粮食。而由东方相会合，需要二十日，届时丞相您在由斜谷赶来，必定可以在此与我会师，这么一来，可以一举平定咸阳以西。 ...