一个常量引发的思考

 

事出有因：

农历xx月xx日，是一个特别的日子，因为用户发邮件说：要将上传附件的大小从原来的5MB提高到10M。

这是多么简单多么合理的一个小变更，处理起来是多么的easy...

 

在代码中，我们是将这个数字定义为常量的:

 

public static final long MAX_SIZE = 5 * 1024 * 1024;

 

 

那修改也很简单，将5改成10即可。

但是当我们将新的class替换到系统上时，发现没有生效，再替换，还是不生效...

就在西二旗城铁站晚高峰快要结束的时候，突然，我灵光一闪，仿佛领悟到了什么，遂将引用这个常量的类也重新编译并替换到生产系统，It works!

 

由此我推测是因为编译器在编译时会对常量进行优化，将其替换为实际的值……

 

 

柳暗花明：

为了验证我的想法，我写了两个类来测试，

T1.java

 

T2.java

 

然后我编译，执行，删除T2.class，再执行。

有点出乎意料啊，和预想的结果并不一致……

就在二路汽车快要收工的时候，突然，我灵光又一闪，仿佛又领悟到了什么，遂将 Long 改成 long:

 

再次编译，执行，删除T2.class，再执行:

It works again!

 

后来又测试了int, Integer, double, Double, String等类型，

并且使用javap -c T1查看反编译结果发现：

 

编译器在编译时会对基本数据类型和String类型进行优化。

 

 

最佳实践：

当系统在线上运行时，如果需要修改某个的常量值（基本类型或String类型），那么引用该常量的所有class都应当重新编译。换句话说：如果A类中使用了B类中的常量（基本类型或String类型），那在系统运行的过程中，你删除掉B.class，不会影响系统的使用。

 

所以如果你不想在后期维护时这么麻烦的话，最好定义变量时使用包装类（Long, Integer等），或者换一种设计方式。

 

比如原来的代码是这样：

HttpUtil类中有一个保存附件的方法

 

public class HttpUtil {
     public static final long MAX_SIZE = 5 * 1024 * 1024;

     public static void saveFile(HttpServletRequest req, long maxSize) {...}
}

 

 

在别的模块如信息发布中有上传附件的功能，会调用HttpUtil的保存文件方法

因为没有对附件的特殊限制，所以使用默认的MAX_SIZE即可：

 

…
HttpUtil.save(req, HttpUtil.MAX_SIZE);
…

 

 

这样的代码就存在前面提到的问题，如果修改常量值就需要重新编译引用常量的类。

但我们可以换一种方式，

在HttpUtil类中增加一个重载方法：

 

public static void saveFile(HttpServletRequest req) {
     saveFile(req, MAX_SIZE);
}

 

 

这样在别的模块需要上传附件并且仅使用默认文件大小限制的时候，就可以调用这个方法。

好处就是现在你再修改MAX_SIZE的值，只需要编译这一个类就可以了。

 

评论

12 楼 hkliya 2011-12-07  

lujiawu12 写道

最初的： public static final Long MAX_SIZE = 5 * 1024 * 1024;   为什么修改不成功？

是在编译过程中做了解箱吗？ 不然按您后来的逻辑应该成功才对。。。

看到最后就这点困惑。。。呵呵

有收获

谢谢，看的很认真呢。
前面是我写错了，应该是long而不是Long

11 楼 lujiawu12 2011-12-07  

最初的： public static final Long MAX_SIZE = 5 * 1024 * 1024;   为什么修改不成功？

是在编译过程中做了解箱吗？ 不然按您后来的逻辑应该成功才对。。。

看到最后就这点困惑。。。呵呵

有收获

10 楼 hiker424 2011-12-07  

看来这2路汽车帮了大忙了，哈哈，顶

9 楼 xiaolv 2011-12-07  

略有小悟   谢了!

8 楼 wangyongjun0901 2011-12-07  

受教了！感谢楼主！

7 楼 chenzhou123520 2011-12-07  

不错，之前没有考虑过这个，楼主挺细心的

6 楼 hkliya 2011-12-07  

stef831018 写道

一个建议：这种配置用途的常量最好放到properties或者xml文件中去，增加一个文件-内存的同步，如果修改了文件，重新刷一遍内存即可，否则，像楼主所说的必须重新编译class文件； 其实主要是因为普通的基本类型常量以及String的常量是在预编译期间直接写到class里的，如果修改必须重新替换。
但是您提到用包装类去实现常量的功能，我真的不建议这样做，因为仅仅为了一个常量问题增加额外的对象在堆上没有太多必要，效率不高；以上个人意见...
另外我也有赶西二旗地铁的习惯，呵呵呵...

谢谢，有道理，我们也通常是写到properties文件中的，但没做内存和文件的同步。
其实这种配置写到数据库也行，用户量不大，上传文件操作不频繁的情况下。

5 楼 stef831018 2011-12-07  

一个建议：这种配置用途的常量最好放到properties或者xml文件中去，增加一个文件-内存的同步，如果修改了文件，重新刷一遍内存即可，否则，像楼主所说的必须重新编译class文件； 其实主要是因为普通的基本类型常量以及String的常量是在预编译期间直接写到class里的，如果修改必须重新替换。
但是您提到用包装类去实现常量的功能，我真的不建议这样做，因为仅仅为了一个常量问题增加额外的对象在堆上没有太多必要，效率不高；以上个人意见...
另外我也有赶西二旗地铁的习惯，呵呵呵...

4 楼 hkliya 2011-12-06  

sunyzc 写道

是因为那个常量值运行之后存储在内存里的吧？

不是的，编译完就删除掉T2.class，T1一样能运行
通过反编译也能看出来

3 楼 yoyo837 2011-12-06  

虽然我习惯把成员变量定义为包装类型,但是也是出于习惯而已,还真不确定基本类型与String的变量虚拟机都搞了什么把戏...

2 楼 ansjsun 2011-12-06  

没遇到过..不过看了这个文章遇到这个问题我就不怕不怕啦

1 楼 sunyzc 2011-12-06  

是因为那个常量值运行之后存储在内存里的吧？