引文
最近在自学python，因而又从头接触了许多基础知识，
在偶然间发现0.1 + 0.2 = 0.30000000000000004，
发现了这个既日常但又被我忽视的现象(在JAVA中相同成立)
因而，就很好奇地探索了一下。
Python中
JAVA中
发生原因
十进制数转化为二进制数
咱们核算的0.1、0.2包括其他都属于十进制数，得通过转化为二进制，才会进行存储和核算。
接下来，咱们分两部分看看是如何转化的。
整数转化
此刻的5代表了第二位的巨细，第二位的位巨细依据咱们刚刚除二，反推等于12 = 2
现在 10 = 01 + 52
咱们接着除于2，得到余数1，商为2
此刻的商2代表了第三位的巨细，第三位的类推等于122 = 4
更新为 10 = 01 + 12 + 24，
以此类推，直到咱们的商为0，则完毕
咱们的十进制数伴随着不断地被除，余数只会越来越小，并且必定能够被完成核算和表明
小数转化
小数部分，如果咱们在二进制的某一位存在1，那么咱们乘以2的位数次方，成果的整数部分会大于1
如 010b = 0.25，第二位存在1，乘数也便是2的2次方 ，0.252 = 1
依据这个原理，咱们每次乘以二，记下整数位为当前位的数字(0、1)，
记载下积的小数部分，再次乘以二，做相同的递归处理，直到积为0
以0.625为例子，0.6252 = 1.25> 1 ，阐明该值大于0.5,取整数位为1,取积的小数部分0.25
再把0.25 2 = 0.5 < 1
取整数位为0 , 取积的小数部分0.5(此刻的积的小数部分现已被乘了2)
终究0.5 2 = 1.0 = 1 小数部分为0，即为完毕
好，那么尝试核算一下0.1,0.2对应的二进制数
0.1 = 0.00011001100……(无限重复1100)
0.2 = 0.001100110011……(无限重复0011)
都是无限循环的小数
从推理进程来看，0.1 -> 0.2 -> 0.4 -> 0.8 -> 0.6 -> 0.2,
小数部分核算后回到了原点，导致了循环，存在一些小数乘以的2任意次方都无法使得小数位为0
既然是无限循环，核算机的空间是有限的，不管采纳何种存储策略，必定只能截取部分数据
也便是精度丢掉了
浮点数存储(IEEE 754)
把十进制转化为二进制后，咱们完成是通过浮点数来存储二进制数据
首要通过科学计数法表明
10.625 = 1010.101 = 1.010101 10^-4
接下来只需要按三部分存储数据，存储正号、10的次方数(4)、以及1后的小数点数据(010101)
咱们再看看0.1的存储
前面提到了无限小数被截取，本应该终究一位为0，此处却为1，
这是因为被截取的下一位为1，1100 截断 1100
这儿为了更靠近原值而零舍一入，终究四位于是变成了1101
所以终究存储的值是比原值稍大的
作为比照咱们看看零舍的0.9
总结
小数在十进制转化二进制的进程会或许发生无限循环的情况，
并且依据浮点数的零舍一入的法则，终究存储的数据都不是一个准确的数据，或许或大或小
0.1和0.2的存储值都是比原值稍大，所以终究的值也是稍大于原值
解决办法
前面咱们介绍到整数是能够在有限的空间存储的性质，小数的存储是导致不准确的诱因，
那么咱们去掉小数，全部转化为整数存储核算！
BigDecimal
咱们分别通过字符串和字面量传入BigDecimal，检查成果
能够看到，通过字符串传入的成果契合咱们的预期，而直接传入的成果依然存在误差。
直接传入的内部完成
通过字符串传入的完成
完成原理
通过前面的进程，咱们能够看出
Bigdecimal是通过输入字符串，而非浮点数(浮点数本身就存在误差)，
便是通过去掉小数点，用一个scale来记载小数的位数，把所有的数字用long来记载，完成准确核算。
public class BigDecimal {
// 小数位数，相似于指数
private final int scale;
// 总位数
private transient int precision;
// 字符串缓存
private transient String stringCache;
// long存储的整形数据
private final transient long intCompact;
}
运用BigDecimal解决0.1+0.2问题
代码
成果
结束
网上相似的文章有许多，
这儿以个人的了解尽或许从基础的视点去阐释这个问题，希望对你有所协助！
END!
