java 游戏服务器怎么实现热更新？

osgi框架

用Classloader载入，用此ClassLoader反射响应请求，就好

以前我在游戏公司上班的时候考虑过这个问题。

一种是 Java 有一个什么机制（忘了名字，去网上搜吧）可以在 JVM 运行阶段动态替换类方法的实现。Eclipse 的 debug 模式好像就是用这种方法来允许你调试的时候动态改代码的。

这种模式有个问题，如果是生产服务器用这个热更新的话，比较乱来，不够让人安心。

另一个方案就是如楼上所说的 ClassLoader。

这个方案比上一个方案要安全得多。但是存在两个问题。

1. 比较难管理。Java 无法主动卸载 ClassLoader 实例，只能等实例变成不可达，然后等 GC 清理掉。这要求你清楚的知道 ClassLoader 会被哪些（有一堆乱七八糟的候选项目）对象直接或间接引用。

这必须要求你的服务器业务模块之间藕合度极低（主要是模块之间调用传的参数和返回值必须是Java标准对象，不可直接或间接引用各种需要 ClassLoader 载入的封装对象）。如果做不到，你的生产服务器可能同时运行新旧两种业务代码，就只好哭爹喊娘了。

对于游戏服务器业务，好像很不好写啊。又不是 servlet，servlet 就随随便便热加载。

2. 如果你不幸生产服务器使用的是 Java 6 以及以下版本，那么你可能会遇到方法区内存用光的问题。如果你使用 Java 7 ，那恭喜你，Java 7 的方法区取消了，直接挪堆区，你完全不必关心这个问题。GC 迟早能卸载旧的代码。

最后，这两种方案最终没有一种被弃用。还是按照老方法要更新服务器就重启服务器，全服玩家全部滚下线候着吧。以上只是纸上谈兵。

那是叫 hostswap 吧，这东西在线上使用不靠谱吧
hotswap 要求不能有结构性变化才能成功，结构性变化就是说不能有 class / member / method 的任何变更，也就是说只能有实现变更
也有比如 jrebel 这样的东西支持结构变更的 hotswap 但感觉更不靠谱了

建议还是用传统的方式吧，比如 tomcat8 支持的 webapp versioning，也就是说同一个 app 的两个不同版本可以同时上线，新版本上线不影响旧版本的 app 继续为已经在服务中的任务进行处理