先说结论
务必使用BigDecimal.valueOf(1.01)，或者使用 new BigDecimal("1.01")———— 而不要使用new BigDecimal(1.01)
查看源码可以知道，BigDecimal.valueOf(double val)的底层是return new BigDecimal(Double.toString(val));
如下图，源码中 “是把double先转换成字符串，再转BigDecimal” 。源码文档中也说明了参数直接为double的精度问题。
第二句中说了建议使用new BigDecimal(String val)的方式，而不要使用new BigDecimal(Doubleval)；
而且最后一句也说了建议使用BigDecimal.valueOf(double)方式；
——————————————————
正文
我们基本已经形成了常识，需要用到金钱的地方要用 BigDecimal 而不是其他，而我们也都知道浮点型变量在进行计算的时候会出现丢失精度的问题。
那么，你知道其实 BigDecimal 也会丢失精度吗？而使用 BigDecimal 的背后又有什么值得去探究的地方吗？今天，告诉你，知其然，也知其所以然。
如下一段代码：
System.out.println(0.05 + 0.01);
System.out.println(1.0 - 0.42);
System.out.println(4.015 * 100);
System.out.println(123.3 / 100); 输出：
0.060000000000000005
0.5800000000000001
401.49999999999994
1.2329999999999999
可以看到在 Java 中进行浮点数运算的时候，会出现丢失精度的问题。那么我们如果在进行商品价格计算的时候，就会出现问题。
很有可能造成我们手中有 0.06 元，却无法购买一个 0.05 元和一个 0.01 元的商品。
因为如上所示，他们两个的总和为 0.060000000000000005。
这无疑是一个很严重的问题，尤其是当电商网站的并发量上去的时候，出现的问题将是巨大的。可能会导致无法下单，或者对账出现问题。所以接下来我们就可以使用 Java 中的 BigDecimal 类来解决这类问题。
普及一下：
Java 中 float 的精度为 6-7 位有效数字。double 的精度为 15-16 位。
API
构造器：
构造器 描述
BigDecimal(int) 创建一个具有参数所指定整数值的对象。
BigDecimal(double) 创建一个具有参数所指定双精度值的对象。
BigDecimal(long) 创建一个具有参数所指定长整数值的对象。
BigDecimal(String) 创建一个具有参数所指定以字符串表示的数值的对象。函数：
方法 描述
add(BigDecimal) BigDecimal对象中的值相加，然后返回这个对象。
subtract(BigDecimal) BigDecimal对象中的值相减，然后返回这个对象。
multiply(BigDecimal) BigDecimal对象中的值相乘，然后返回这个对象。
divide(BigDecimal) BigDecimal对象中的值相除，然后返回这个对象。
toString() 将BigDecimal对象的数值转换成字符串。
doubleValue() 将BigDecimal对象中的值以双精度数返回。
floatValue() 将BigDecimal对象中的值以单精度数返回。
longValue() 将BigDecimal对象中的值以长整数返回。
intValue() 将BigDecimal对象中的值以整数返回。由于一般的数值类型，例如 double 不能准确的表示 16 位以上的数字。
BigDecimal 精度也丢失
我们在使用 BigDecimal 时，使用它的 BigDecimal(String) 构造器创建对象才有意义。其他的如 BigDecimal b = new BigDecimal(1) 这种，还是会发生精度丢失的问题。如下代码：
BigDecimal a = new BigDecimal(1.01);
BigDecimal b = new BigDecimal(1.02);
BigDecimal c = new BigDecimal("1.01");
BigDecimal d = new BigDecimal("1.02");
System.out.println(a.add(b));
System.out.println(c.add(d));输出：
2.0300000000000000266453525910037569701671600341796875
2.03
可见论丢失精度 BigDecimal 显的更为过分。但是使用 Bigdecimal 的 BigDecimal(String) 构造器的变量在进行运算的时候却没有出现这种问题。
究其原因计算机组成原理里面都有，它们的编码决定了这样的结果。
long 可以准确存储 19 位数字，而 double 只能准备存储 16 位数字。
double 由于有 exp 位，可以存 16 位以上的数字，但是需要以低位的不精确作为代价。如果需要高于 19 位数字的精确存储，则必须用 BigInteger 来保存，当然会牺牲一些性能。
所以我们一般使用 BigDecimal 来解决商业运算上丢失精度的问题的时候，声明 BigDecimal 对象的时候一定要使用它构造参数为 String 的类型的构造器。
同时这个原则 Effective Java 和 MySQL 必知必会中也都有提及。float 和 double 只能用来做科学计算和工程计算。商业运算中我们要使用 BigDecimal。
而且我们从源码的注释中官方也给出了说明，如下是 BigDecimal 类的 double 类型参数的构造器上的一部分注释说明：
* The results of this constructor can be somewhat unpredictable.
* One might assume that writing {@codenew BigDecimal(0.1)} in
* Java creates a {@code BigDecimal} which is exactly equal to
* 0.1 (an unscaled value of 1, with a scale of 1), but it is
* actually equal to
* 0.1000000000000000055511151231257827021181583404541015625.
* This is because 0.1 cannot be represented exactly as a
* {@codedouble} (or, for that matter, as a binary fraction of
* any finite length). Thus, the value that is being passed
* in to the constructor is not exactly equal to 0.1,
* appearances notwithstanding.
……
* When a {@codedouble} must be used as a source for a
* {@code BigDecimal}, note that this constructor provides an
* exact conversion; it does not give the same result as
* converting the {@codedouble} to a {@code String} using the
* {@link Double#toString(double)} method and then using the
* {@link #BigDecimal(String)} constructor. To get that result,
* use the {@codestatic} {@link #valueOf(double)} method.
*
public BigDecimal(double val) {
this(val,MathContext.UNLIMITED);
} 第一段也说的很清楚它只能计算的无限接近这个数，但是无法精确到这个数。
第二段则说，如果要想准确计算这个值，那么需要把 double 类型的参数转化为 String 类型的。并且使用 BigDecimal(String) 这个构造方法进行构造。去获取结果。
正确运用 BigDecimal
另外，BigDecimal 所创建的是对象，我们不能使用传统的 +、-、*、/ 等算术运算符直接对其对象进行数学运算，而必须调用其相对应的方法。方法中的参数也必须是 BigDecimal 的对象，由刚才我们所罗列的 API 也可看出。
在一般开发过程中，我们数据库中存储的数据都是 float 和 double 类型的。在进行拿来拿去运算的时候还需要不断的转化，这样十分的不方便。这里我写了一个工具类：
/**
* @author: Ji YongGuang.
* @date: 19:50 2017/12/14.
*/
publicclass BigDecimalUtil {
private BigDecimalUtil() {
}
public static BigDecimal add(double v1, double v2) {// v1 + v2
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.add(b2);
}
public static BigDecimal sub(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.subtract(b2);
}
public static BigDecimal mul(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
return b1.multiply(b2);
}
public static BigDecimal div(double v1, double v2) {
BigDecimal b1 = new BigDecimal(Double.toString(v1));
BigDecimal b2 = new BigDecimal(Double.toString(v2));
// 2 = 保留小数点后两位 ROUND_HALF_UP = 四舍五入
return b1.divide(b2, 2, BigDecimal.ROUND_HALF_UP);// 应对除不尽的情况
}
} 该工具类提供了 double 类型的基本的加减乘除运算。直接调用即可。
Java并发基石——所谓“阻塞”：Object Monitor和AQS（1）
通过上文的介绍我们知道就算是“阻塞”状态，根据进入阻塞状态的方式不同，阻塞状态也会有细微的差异。这样的差异基本上分成两种大的类型：Object Monitor和Parking。在本文和后续的几篇文章中，我们将对它们进行详细介绍。我们将首先介绍基于Object Monitor原理的悲观锁实现，然后再讨论基于AQS队列同步框架。
1、所谓“阻塞”——Object Monitor和AQS
在本专题开始的时候曾经通过一张图的方式介绍了线程的几个状态和这几个状态的切换方式，如下图所示：
通过最近几篇文章的介绍，我们知道了就算是“阻塞”状态，也是有区别的。通过不同的阻塞机制可以使线程进入不同的“阻塞”状态。如下图所示：
如上图所示，根据本专题文章的进程，我们将“线程状态”切换这张图进行了“些许调整”。主要调整的是“阻塞”这种状态。我们标识出了不同的方法（或类似的方法）进入的不同阻塞状态，但是由于图片大小原因还不能穷尽所有方法，例如使用ReentrantLock对Condition接口的具体实现中的await方法，也可以使当前线程进入“阻塞”状态（parking）。
从上图中可以看出来，这里的几个主要“阻塞”状态可以归纳为“sleeping”、“on object monitor”、“parking”以及一种“BLOCKED”的阻塞状态。实际上这几种有细节区别的“阻塞”状态，恰恰就是Java中不同的锁机制实现。
2、Object Monitor机制
在本专题之前的文章中我们提到，Java中对悲观锁思想的实现就是我们最常使用的synchronized同步块。而Object Monitor机制就是synchronized同步块锁机制升级为“重量级锁”后的工作机制。本节我们首先讲解synchronized和锁升级过程，然后再讲解Object Monitor机制的工作过程。
2.1、synchronized和锁升级过程 2.1.1、和synchronized有关的对象结构
Java对象结构中的对象头描述部分是实现锁机制的关键，实际上在HotSpot JVM 虚拟机的工作中将对象结构分为三大块区域：对象头（Header）、实例数据（Instance Data）和对齐填充区域（可能存在）。如下图所示：
注意：整个对象头的描述结构的长度并不是固定不变的，首先在32位操作系统和64位操作系统中就有结构长度上的差异。另外在启用的对象指针压缩和没有启用对象指针压缩的情况下，整个对象头的长度也不一样：64位平台下，原生对象头大小为16字节，压缩后为12字节。
这里我们重点讨论和synchronized加锁过程有关的markword区域，首先需要说明几点：
2.1.2、synchronized关键字下的锁状态升级
通常情况下，我们在代码中使用synchronized关键字协调多个线程的工作过程，实际上就是使用Object Monitor控制对多个线程的工作过程进行协调。synchronized关键字的执行过程从传统的理解上就是“悲观锁”设计思想的一种实现。但实际上synchronized关键字的执行过程还涉及到锁机制的升级过程，升级顺序为 自旋锁、偏向锁、轻量级锁、重量级锁。
2.2、Object Monitor区域和工作过程
正所谓Object Monitor机制的名称一样，它就是以Java对象为基础的，在多线程环境下对特定对象的操作权限的一种控制方式。在这种控制方式中有三个象限：
============================================================
（接下文）
