开发注意事项
一、多线程下注意事项
在多线程的环境下使用了一些非线程安全的类，操作的时候也没有加锁就有可能发生一系列的问题。
实例：某项目在开发的时候用的是HashSet类(这个类是线程不安全的)，在多线程同时向同一个HashSet对象中添加数据，有可能导致内部死锁,并且如果循环这个HashSet的话，还会导致死循环，原因是因为多线程触发hashmap进行rehash操作时,可能会形成环形链表,循环环形链表会死循环
解决：这种在多线程环境下使用的集合类要特别小心，一不小心就会出现问题，甚至死锁，死循环，问题是致命的，所以建议在多线程的情况下，使用线程安全的集合类或者加锁，避免这种问题发生。
二、DB相关注意事项
2.1 关于DB的事物的提交和回滚，
有些操作会牵扯到内存操作同时也会进行DB操作，如果写的不好，一不小心就会出现严重问题。
实例：某项目在开发中在service中已经进行了扣除(数据库操作)和发奖(内存操作),但是在后续记录日志时引发了报错,导致数据库回滚,但是奖励已经发送给玩家,导致玩家一直刷了很多东西，扣除和发奖所在的层级不同,导致一次操作不是原子性的,只回滚了一部分。
解决：有三种思路
1.可以在service中增加try-catch,报错回滚后撤回内存级奖励
2.也可以扣除在service中处理,发奖在service执行完毕后出来发送
3.发送奖励后的操作(如:日志)尽量不要放在service中记录,如果一定要在service中记录,记得加上try-catch
2.2 关于IEntity实体类中属性定义为不要定义为基础类型(int,byte,double,long等基础类型)
如果你将IEntity实体类中属性定义定义为基础类型,那每次使用DAOHelper.update/merge方法都会将持久化IEntity中不为null的属性
解决：实体类IEntity不要使用基础类型。
三、游戏缓存类的正确使用
所有的游戏玩家类都会继承AbsCacheState，而这个AbsCacheState抽象类默认有个属性state，所有玩家的缓存类中不要在定义这个属性了，不然会覆盖抽象类的state了，还有缓存修改后，记得一定要将其状态改变(不修改的话，是不会入库的，当重启应用或者缓存自动过期后，数据将永久丢失，问题会很严重），还有缓存提供了很多种类型的抽象缓存，根据自己的业务需求来使用不同的抽象缓存。
四、游戏基础数据的正确使用。
游戏的基础数据默认在游戏启动后，会从DB中初始化，后期如果不是需要重新加载的话，是不会更改的，所以开发中，理解成基础数据应该是只读的，不可更改。还有加载基础数据的时候要根据业务来判断加载基础数据的哪些信息，不要不管三七二十一全部加载进来。
五、游戏的扩展设计
一般游戏的一些业务会不停的增加和修改，合理的灵活的设计，未后期增加和修改奠定了非常好的基础，当然一旦设计不当，后期修改可能就是重新来做，可见前期设计的重要性。
举例：一般游戏都会有战报，战报设计的时候，一定要把战报版本号加入，避免战斗修改后，老版本与新版本不兼容，无法区分。
六、关于socket通讯
服务端受到来自客户端的通讯消息后，一定要对其参数进行有效的验证，必要的时候，有些还需要在计算完后的值进行校验判断，避免出现问题和漏洞。还有就是由于目前客户端在接收服务端发送过来的包的大小设置了限制，所以在发大数据包的时候，主要看下是否会超出客户端接收包的限制，如果是的话，服务端需要将大包拆分成多个小包发送给客户端处理。当然服务端器与服务器之前的通讯一般也是有大小限制的，建议一次不要大小，还有有条件的话，可以把打包压缩后再发送。
七、tomcat操作注意事项
目前一般tomcat部署应用都是在tomcat目录下的conf/Catalina/localhost配置ROOT.xml的docBase属性配置好部署的应用目录，但这个应用目录在tomcat启动期间不要做迁移操作或者改名，否则tomcat会监听到部署的目录不存在自动销毁掉ROOT.xml，也就是说如果你真的这么做了，下次启动tomcat会发现ROOT.xml不见了，那这么tomcat也就不是部署你这个应用的事情了，变成了跑一个空的tomcat服务罢了。