开发小技巧系列文章，是本人对过往平台系统的设计开发及踩坑的记录与总结，给初入平台系统开发的开发人员提供参考与帮助
在过去做项目的某一天中，突然有小伙伴说两个BigDecimal的数据相除（divide）报错了，觉得不可能，然后问他是怎么编写的，他说很简单呀，就是new了2个BigDecimal，然后相除的结果赋值给另外一个BigDecimal对象。听起来觉得没有问题，正常来说，2个Integer(int)，2个Double(double）都不会报错，然后问是什么异常，说是一个很奇怪的异常。
问不出情况，直接看代码吧（省去了一些其他无关的代码）
//省略业务的逻辑 ...
//得到订单金额
BigDecimal orderAmount = new BigDecimal(2312.23);
//得到成本
BigDecimal cost = new BigDecimal(984.23);
//得到客户数
BigDecimal customerCount = new BigDecimal(35);
//得到客单价
BigDecimal pricePerCustomer = orderAmount.divide(customerCount);
log.info("客单价：{}", pricePerCustomer);
//得到毛利率
BigDecimal profit = (orderAmount.subtract(cost)).divide(cost);
log.info("毛利率：{}", profit);
//省去其他逻辑...
代码看起来没什么问题（一般的小伙伴），为什么会报错呢？来看下异常信息，如下：
11:01:10.027 [main] INFO net.jhelp.demo.BigDecimalTest - 客单价：66.06371428571428623399697244167327880859375
java.lang.ArithmeticException: Non-terminating decimal expansion; no exact representable decimal result.
at java.math.BigDecimal.divide(BigDecimal.java:1690)
异常的信息是：
算术运算异常：相除结果为无限小数；没有可精确表示的计算结果。
从异常中可以看出是“计算结果除不尽，没办法确定相除的结果”，从这个信息的提示上看，是要给BigDecimal的“商”设置计算结果的“小数位”。
但是很奇怪，上面的程序中有2处用了divide方法，一处没有报错，一处报错，也就是用divide方法不一定会抛出上面的异常，带上面的问题，来调试一下程序，找到BigDecimal的divide方法在里设置一个断点，当执行到第一个divide时的调试如下：
从上面可以看到，在代码里面直接new BigDecimal(2312.23)，实际上在程序运行时，它变成了一个带41位小数的浮点数（scale=41)（题外话：在构造确实数值时，还是使用new BigDecimal("2312.23"），这样出来就不会带过的小数位），另外一个数值为new BigDecimal(35),就是35的值，精度为0(scale=0)。图上还看到一个属性（intCompact），有不同的值(-9223372036854775808, 35).
new BigDecimal(2312.23)实际上调用的是BigDecimal中的浮点数构造方法：
public BigDecimal(Double value){
.....
this.intVal = intVal;
this.intCompact = compactVal;
this.scale = scale;
this.precision = prec;
}而new BigDecimal(35)调用的是BigDecimal中的整数构造方法：
public BigDecimal(int val) {
this.intCompact = val;
this.scale = 0;
this.intVal = null;
}再继续往下走，来看看preferredScale（预期的小数位精度）是多少。
这时的preferredScale=41, 继续往下看。
从上图中看到，BigDecimal在计算2个除数的商时，如果被除数是整数，那商的精度由除数的精度决定（从计算preferredScale可以看出）。另外，还生成了一个MathContext的对象，默认进位规则是：RoundingMode.UNNECESSARY。
这里面有一个重要的分支
当BigDecimal是一个浮点类型的数时，它的intCompact是和INFLATED的值相同的。
方法的调用流程是这样：
最终返回一个跟“除数”一样精度的“商”值。
来看第二个divide的跟踪过程
.png)
.png)
第二个divide的除数，被除数的scale=41, intCompact的值相同（-9223372036854775808==INFLATED），preferredScale=0，而这时的MathContext 与前一个有很大的不同，它的precision=192.
.png)
this.precision() = 45
(long)Math.ceil(10.0*divisor.precision()/3.0 = 147而在这个逻辑分支时，2个浮点相除的，走的是下面的方法，和第一个计算时走的分支是不同的，第一个计算走的是上面的方法。
.png)
来看看它的方法调用流程：
.png)
.png)
/**
* Shared logic of need increment computation
. */
private static boolean commonNeedIncrement(int roundingMode, int qsign, int cmpFracHalf, boolean oddQuot) {
switch(roundingMode) {
case ROUND_UNNECESSARY:
throw new ArithmeticException("Rounding necessary");
case ROUND_UP: // Away from zero
return true;
case ROUND_DOWN: // Towards zero
return false;
//略...
}跟踪到这里，是不是清晰很多了，这里的roundingMode就是在调用divide的方法中获取的，也是是前面的MathContext对象生成时，默认设置的RoundingMode.UNNECESSARY，从这个方法的调用过程中，可以看出divide(BigDecimal divisor）方法不适合用于2个数都是“浮点数“的场景的相除。（题外话，这里抛出的异常，与外面见到的异常是不一样的，有点坑，为什么这个方法不标志一下@Deprecated，让别人不要掉坑里。）
总结
上面根据异常的信息，对BigDecimal的divide（除法）的源代码分析与跟踪，分析出现问题的原因，在开发的过程中，不要使用divide(BigDecimal divisor）这方法，以免掉到坑里，尽理使用divide(BigDecimal divisor, int scale, int roundingMode)这种，指定精度，和“舍入规则”。
<end>
文字点滴，希望你能收获点滴，觉得不错的可以点个赞。
开发小技巧系列文章：
3. 开发小技巧系统 - Java实现树形结构的方式有那些？
4. 开发小技巧系列 - 如何避免NullPointerException？（一）
5. 开发小技巧系列 - 如何避免NullPointerException？（二）
