BigDecimal在Debug模式下诡异的行为
前言
同事在一次偶然的Debug过程中，发现了一件不可思议的事情，程序在Run和Debug模式下运行结果居然不一致!
问题复现
测试代码很简单，堪比Hello world。
public class Main {
public static void main(String[] args) {
BigDecimal a = new BigDecimal("123.455");
System.out.println("结果是 -> " + a);
}
}
这段程序会输出什么？
脑编译一波，输出结果结果是 -> 123.455。
IDEA中Run模式跑一把儿，验证一下
image.png
一切看起来很合理，不过，我对BigDecimal解析字符串的过程有点兴趣，在构造函数上打个断点跟踪调试一下
image.png
现在以Debug模式启动，一路next后，看看控制台输出
image.png
诡异的事情发生了，结果居然是0。
image.png
问题研究
现在再加两行代码看看
public class Main {
public static void main(String[] args) {
BigDecimal a = new BigDecimal("123.455");
System.out.println("结果是 -> " + a);
BigDecimal b = a.add(BigDecimal.TEN);
System.out.println("加10，结果是 -> " + b);
}
}
Run模式启动
image.png
Debug模式启动
image.png
问题似乎变得更诡异了。。。
一波冷静思考（瞎折腾）后，貌似找对了方向。
接下来尝试对修改后程序Debug模式下的调试结果进行解释：
首先，我们来整理一下思路：
- 控制台打印结果时，调用的是
BigDecimal.toString()方法； - 打印出
a错误的结果0； -
a + 10之后，将结果赋予b，打印出正确的结果133.45；
这样看来，问题极有可能出在BigDecimal.toString()方法中！
OK，看看这段代码。
@Override
public String toString() {
String sc = stringCache;
if (sc == null)
stringCache = sc = layoutChars(true);
return sc;
}
很明显，这里做了一个缓存，真正的字符串生成在layoutChars()，进去看一下，过程还是有些复杂的，加一个缓存减少计算量的确是一个明智的设计。
那么这个诡异的现象就很好解释了，肯定是stringCache这个作为缓存的成员变量被污染了。
下面开始搜索stringCache变量被引用的位置，发现只有toString()方法这两处，那也就是说，debug模式下，过早的调用了toString()方法。因为我们把断点打在了构造函数上，这时BigDecimal对象还没有构造完成，调试器在展示对象值的时候，通过特殊方式调用了toString()方法，污染了stringCache缓存，也就导致了后续调用toString()方法时一直拿到的都是这个脏缓存。
image.png
PS：我把断点打在toString()方法里，发现并没有拦住，IDEA给了一句这样的提示：
image.png
扩展思考
在toString()方法中使用缓存的我还是第一次见，平时我们写POJO时，IDE生成的代码都是直接拼接，为什么不也生成一个带缓存的方法？
问题的关键点是BigDecimal对象是不可变对象。
不可变对象也就意味着对象一旦构造完成后，不可再改变。如果需要修改，原来的对象不变，生成一个新对象。
乍一看起来，这似乎是一个非常奢侈的举动，会浪费大量的内存。但带来的好处却也是巨大的：
- 在Java中，所有的对象都是引用类型，在修改一个对象时，会影响该对象的所有持有者，导致一些难以排查的问题。
- 不可变对象对函数式编程和并发编程是极其友好的，对象不可变意味着不用加锁，提高了性能，并降低了开发难度。
- 不可变对象可以使用缓存技术提高性能，例如JVM针对Integer、String等类型会维护常量池。
我们再来分析一下BigDecimal.toString()方法使用的缓存设计。
- 首先，BigDecimal是一个不可变对象，Java标准要求对象必须在构造完成后才能调用方法，因此在程序正常Run过程中，是没有任何问题的，但是debug过程采用的特殊方式提前调用了
toString()方法，其实是破坏了这种约定，才导致的诡异现象发生。 - 其次，这是一个懒加载缓存，只有在首次调用
BigDecimal.toString()时，才触发stringCache的更新，在实际的使用中，我们并不总会将BigDecimal对象按字符串输出，这样也就不会触发stringCache的计算，降低性能开销。
Date类的设计一直饱受争议，其可变性就被认为是一个设计的失误。
比如如下代码
public class Person {
private Date birth;
public Date getBirth() {
return birth;
}
public void setBirth(Date birth) {
this.birth = birth;
}
public static void main(String[] args) {
Person person = new Person();
person.setBirth(new Date(2000 - 1900, 0, 1));
System.out.println(person.getBirth());
Date date = person.getBirth();
date.setMonth(1);
System.out.println(person.getBirth());
}
}
这段代码的输出是
Sat Jan 01 00:00:00 CST 2000
Tue Feb 01 00:00:00 CST 2000
想象一下，如果person是从数据库里读取出来的一条记录，我们仅仅是想得到person生日那年的一个2月份时间，却在不经意间改变了person本身的birth属性，在某些ORM框架中，即使没有显示调用update操作，对person的修改也会保存到数据库，这种问题带来的影响是十分难以排查的。
但是如果Date是不可变类型，对于每一次的修改实际是生成了一个新对象，那么上述问题将不复存在。基于此，Java 8全新的Time API都是不可变的。
最后，我们看一下LocalDate.toString()源码
@Override
public String toString() {
int yearValue = year;
int monthValue = month;
int dayValue = day;
int absYear = Math.abs(yearValue);
StringBuilder buf = new StringBuilder(10);
if (absYear < 1000) {
if (yearValue < 0) {
buf.append(yearValue - 10000).deleteCharAt(1);
} else {
buf.append(yearValue + 10000).deleteCharAt(0);
}
} else {
if (yearValue > 9999) {
buf.append('+');
}
buf.append(yearValue);
}
return buf.append(monthValue < 10 ? "-0" : "-")
.append(monthValue)
.append(dayValue < 10 ? "-0" : "-")
.append(dayValue)
.toString();
}
这里貌似没有使用类似BigDecimal的缓存，不知道设计人员是不是也考虑到了BigDecimal在debug下可能会产生一些问题，亦或者是感觉缓存带来的性能优化是寥寥无几的。
