距离上一次更新博客，确实是有很长一段时日了，我想忙并不是一个借口，而是真忙啊！上次游戏封测还是遇到了很多问题，尤其是对于我这个半路出家的java程序来说，遇到了超级多的问题，还好还要，有很多流传的服务器代码可以参考，也有很多热心的网友的回答。这篇博客说说上次封测遇到的问题吧！
　　首先说说定时器的问题吧，这套java服务器里面用的是 TimerEvent，但是我万万没有想到，java里面用TimerEvent开启一个定时器，开启了一个线程，我在做设计的时候，遵循了之前C++工程的设计，几乎每个玩家身上都有2-3个定时器，每个地图场景上面也有一个定时器，在加上一些开发者的使用不当，在玩家下线的时候，没有能将定时器清理掉，所以导致在游戏在开服后，十几个小时候之后会因为内存不足以开启新线程而死掉被迫重启。刚开始遇到这个问题的时候，我还以为是内存泄露的问题导致，也是在无意间发现的这个问题，算是给我这个半路出家的java程序一个教训吧！
　　解决方案:
　　在每个玩家身上放一个心跳函数，保持心跳函数一秒钟运行一次！
　　新定义一种定时器的结构: HeartTimer 去做是否是否到时的校验！代码如下：
　　说一个死循环的问题吧，策划有这样一个需求，是有一种道具在插入背包的时候，要自动使用，于是我这样写了一段代码。
　　策划在简单测试之后告诉我，不行，不能只是用一个，所有的都使用。于是函数变成了这样子
　　于是悲剧发生，因为我无法确定调用wp.use的时候，一定能成功，比如消耗物品得到体力，但是体力值有上限，到达上限之后，物品无法使用，个数也不会减一。于是调整这个函数为下面这个样子。
　　不得不承认，控制循环次数的for 循环优于条件判断的while循环。
　　说说一些刷道具的情况吧。这个属于对逻辑校验不够严谨的问题了。比如说玩家主动奖励，这里一定要做充分的校验。还有是升级技能的时候，这里有一个比较典型的问题，当客户端发1表示普通升级，发送2表示元宝升级的时候，那么非上面两种情况一定要校验，并且抛出异常，因为这里很容易出现漏洞，并且被玩家外挂所利用。
　　说说数据库存储的问题。在接到这个项目的时候，这个项目用的mysql数据库，在玩家表里面定义了很多blob字段，用于存储玩家的数据，采用序列化的形式，通过byte数组，将玩家的等级，经验，坐标啦等一些列数据拼装在一起。这种格式带来了两种不变。1：数据库不直观，没有办法通过查询数据库获取玩家的数据；2：可扩展性差，php无法解析。
　　存储和读取都是类似于这种格式
　　修改方案：引入json库，采用json字符串去存储玩家数据，并且将mysql里玩家的数据表字段调整为text，这样可以很直观的查看玩家的数据，而且可扩展性方面大大提高了。
　　说道这里吧，欢迎大家提出更好的建议！