前言

同事在一次偶然的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下可能会产生一些问题，亦或者是感觉缓存带来的性能优化是寥寥无几的。