共计 4108 个字符，预计需要花费 11 分钟才能阅读完成。
1 计算器的劫难:10%+10% 到底等于几？
- 咱们人类认为是 0.2，可是关上手机计算器试试呢？
解密
国外计算程序应用的单步计算法。于是，a+b% 示意 a (1+b%)。所以，手机计算器实际上在计算 10%（1+10%）= 0.11。
再艰深点一句话说清运算原理。以 8 +10% 为例，为什么 =8.8 而不是 8.1？一起读：8 元钱，加上 10% 的小费，一共是 8.8 元。
最早的电子计算器并没有 %，是起初加的。作为后续改良，它肯定解决了计算场景中的罕用痛点，而绝不是脑残。我揣测很可能是西方人计算折扣、小费、利息等常见场景。
2 满目疮痍的 Double
- 浮点数四则运算
- 后果
因为计算机外部是以二进制存储数值的，浮点数亦是。Java 采纳 IEEE 754 规范实现浮点数的表白和运算。比方，0.1 的二进制示意为 0.0 0011 0011 0011…（0011 有限循环)，再转换为十进制就是 0.1000000000000000055511151231257827021181583404541015625。计算机无法准确示意 0.1，所以浮点数计算造成精度损失。
你可能感觉像 0.1，其十进制和二进制间转换后相差很小，不会对计算产生什么重大影响。但积土成山，大量应用 double 作大量金钱计算，最终损失精度就是大量资金出入了。
一位“黑客”利用银行破绽从 PayPal、Google Checkout 和其它在线领取公司窃取了 5 万多美元，每次只偷几美分。他所利用的破绽是：银行在开户后个别会向帐号发送小额钱去验证帐户是否无效，数额个别在几美分到几美元左右。Google Checkout 和 Paypal 也应用雷同的办法去测验与在线帐号捆绑的信用卡和借记卡帐号。用一个主动脚本开了 58,000 个帐号，收集了数以千计的超小额费用，汇入到几个集体银行账户中去。从 Google Checkout 服务骗到了 $8,000 以上的现金。银行留神到了这种奇怪的现金流动，和他取得联系，Largent 解释他仔细阅读过相干服务条款，置信 本人没做错事，宣称须要钱去偿还债务。但 Largent 应用了假名，包含卡通人物的名字，假的地址和社会保障号码，因而了违反了邮件、银行和电信坑骗法律。别在中国尝试，这要判无期徒刑。
3 救世的 BigDecimal
咱们晓得 BigDecimal，在浮点数准确表白和运算的场景，肯定要应用。不过，在应用 BigDecimal 时有几个坑须要避开。
- BigDecimal 之前的四则运算
- 输入
运算后果还是不准确，只不过是精度高了。
3.1 BigDecimal 示意 / 计算浮点数且应用字符串结构器
- 完满输入
无奈调用 BigDecimal 传入 Double 的结构器，但手头只有一个 Double，如何转换为准确表白的 BigDecimal？
- Double.toString 把 double 转换为字符串可行吗？
- 输入
401.5000。与下面字符串初始化 100 和 4.015 相乘失去的后果 401.500 相比，这里为什么多了 1 个 0？BigDecimal 有 scale 小数点左边的位数 precision 精度，即有效数字的长度
new BigDecimal(Double.toString(100))失去的 BigDecimal 的 scale=1、precision=4；而
new BigDecimal(“100”) 失去的 BigDecimal 的 scale=0、precision=3。
BigDecimal 乘法操作，返回值的 scale 是两个数的 scale 相加。所以，初始化 100 的两种不同形式，导致最初后果的 scale 别离是 4 和 3：
private static void testScale() {BigDecimal bigDecimal1 = new BigDecimal("100");
BigDecimal bigDecimal2 = new BigDecimal(String.valueOf(100d));
BigDecimal bigDecimal3 = new BigDecimal(String.valueOf(100));
BigDecimal bigDecimal4 = BigDecimal.valueOf(100d);
BigDecimal bigDecimal5 = new BigDecimal(Double.toString(100));
print(bigDecimal1); //scale 0 precision 3 result 401.500
print(bigDecimal2); //scale 1 precision 4 result 401.5000
print(bigDecimal3); //scale 0 precision 3 result 401.500
print(bigDecimal4); //scale 1 precision 4 result 401.5000
print(bigDecimal5); //scale 1 precision 4 result 401.5000
}
private static void print(BigDecimal bigDecimal) {log.info("scale {} precision {} result {}", bigDecimal.scale(), bigDecimal.precision(), bigDecimal.multiply(new BigDecimal("4.015")));
} 4 浮点数的舍入和格式化
应思考显式编码，通过格式化表达式或格式化工具
4.1 明确小数位数和舍入形式
- 通过 String.format 应用 %.1f 格式化 double/float 的 3.35 浮点数
- 后果
3.4 和 3.3
精度问题和舍入形式独特导致：double/float 的 3.35 理论存储示意
3.350000000000000088817841970012523233890533447265625
3.349999904632568359375 String.format 采纳四舍五入的形式进行舍入，取 1 位小数，double 的 3.350 四舍五入为 3.4，而 float 的 3.349 四舍五入为 3.3。
咱们看一下 Formatter 类的相干源码，能够发现应用的舍入模式是 HALF_UP（代码第 11 行）：
若想应用其余舍入形式，可设置 DecimalFormat
当把这俩浮点数向下舍入取 2 位小数时，输入别离是 3.35、3.34，还是因为浮点数无奈准确存储。
所以即便通过 DecimalFormat 准确管制舍入形式，double/float 也可能产生奇怪后果，所以
4.2 字符串格式化也要应用 BigDecimal
- BigDecimal 别离应用向下舍入、四舍五入取 1 位小数格式化数字 3.35
- 后果
3.3 和 3.4，合乎预期。
最佳实际：应该应用 BigDecimal 来进行浮点数的示意、计算、格式化。
5 equals 做判等就肯定对？
包装类的比拟要通过 equals，而非 ==。那应用 equals 对两个 BigDecimal 判等，肯定合乎预期吗？
- 应用 equals 比拟 1.0 和 1 这俩 BigDecimal：
后果天然是 false。BigDecimal 的 equals 比拟的是 BigDecimal 的 value 和 scale：1.0 的 scale 是 1，1 的 scale 是 0，所以后果 false
若只想比拟 BigDecimal 的 value，应用 compareTo
BigDecimal 的 equals 和 hashCode 会同时思考 value 和 scale，若联合 HashSet/HashMap 可能出问题。把值为 1.0 的 BigDecimal 退出 HashSet，而后判断其是否存在值为 1 的 BigDecimal，失去 false
5.1 解决方案
5.1.1 应用 TreeSet 替换 HashSet
TreeSet 不应用 hashCode，也不应用 equals 比拟元素，而应用 compareTo 办法。
5.1.2 去掉尾部的零
把 BigDecimal 存入 HashSet 或 HashMap 前，先应用 stripTrailingZeros 办法去掉尾部的零。
比拟的时候也去掉尾部的 0，确保 value 雷同的 BigDecimal，scale 也是统一的：
6 溢出问题
所有的根本数值类型都有超出保留范畴可能性。
- 对 Long 最大值 +1
- 后果是一个正数，Long 的最大值 + 1 变为了 Long 的最小值
-9223372036854775808
显然产生溢出还没抛任何异样。
6.1 解决方案
6.1.1 应用 Math 类的 xxExact 进行数值运算
这些办法会在数值溢出时被动抛异样。
执行后，会失去 ArithmeticException，这是一个 RuntimeException：
java.lang.ArithmeticException: long overflow 6.1.2 应用大数类 BigInteger
BigDecimal 专于解决浮点数的专家，而 BigInteger 则专于大数的科学计算。
- 应用 BigInteger 对 Long 最大值进行 + 1 操作。若想把计算结果转为 Long 变量，可应用 BigInteger#longValueExact，在转换呈现溢出时，同样会抛出 ArithmeticException
- 后果
9223372036854775808
java.lang.ArithmeticException: BigInteger out of long range 通过 BigInteger 对 Long 的最大值加 1 无问题，但将后果转为 Long 时，则会提醒溢出。
举荐浏览
为什么阿里巴巴的程序员成长速度这么快，看完他们的内部资料我懂了
字节跳动总结的设计模式 PDF 火了，完整版凋谢下载
刷 Github 时发现了一本阿里大神的算法笔记！标星 70.5K
程序员 50W 年薪的常识体系与成长路线。
月薪在 30K 以下的 Java 程序员，可能听不懂这个我的项目；
字节跳动总结的设计模式 PDF 火了，完整版凋谢分享
对于【暴力递归算法】你所不晓得的思路
开拓鸿蒙，谁做零碎，聊聊华为微内核
=
看完三件事❤️
如果你感觉这篇内容对你还蛮有帮忙，我想邀请你帮我三个小忙：
点赞，转发，有你们的『点赞和评论』，才是我发明的能源。
关注公众号『Java 斗帝』，不定期分享原创常识。
同时能够期待后续文章 ing????
