替换class文件打补丁时值得注意的一个问题

引言

有过一些正式线上运维操作的coding应该会知道这样一个“小窍门”:
在我们代码中出现有些小调整而又需要马上更新线上服务器时，我们可能会把修改好的java文件对应的class文件复制出来，替换掉线上服务器下的class文件，再把服务器重器一下，问题立马解决！但是，这样做真的就没有一点问题吗？最近发生了这样一个事件，看似十分简单的修改，却出现怪异的情况

正文

类A是一个调用类，调用类B中的常量F，现在需求有变，类B中的常量需要修改，按照正常的逻辑，修改类B常量，将类B的class文件替换并重启OK！问题搞定，可结果是问题依旧存在，似乎根本没有修改成功，找了很久的问题依然没有找出原因，脑子里一直有一个感觉就是没有修改成功，可是class文件日期明明已经改变，苦脑很久以后终于找出了问题所在，原因现在的类B确实已经生效，可代码调用的类A已经编译，并没有按我们想象中的“正常取值”的方式从A中取最新的常量，应该是由于常量的原因，JVM对A中的“正常取值”做了优化，常量String经过编译已经写到了A的编译文件中去了，使用Java Decompiler反编译工具查看编译后的内容如下：

反编译的代码

类A源部分代码

map.put(WeChatAPI.NAME_LAIWANBALL, 
	new JobObject(WeChatAPI.APPID_LAIWANBALL,WeChatAPI.APPSECRET_LAIWANBALL));

这里的WeChatAPI主是类B

总结：

替换class文件虽然对于线上出现的“小问题”可以很方便，很迅速的解决，但如果没有一套系统的上线方案来支持，恐怕会事得其反，如果B中的常量起到的是一个决定性因素的代码，那么自以为已经修改成功而使线上继续运行的话，后果将很严重