Java语言你知道或不知道的坑

不管是再好的编程语言，如果使用不当，总能出问题。就好像，车再好也架不住司机师傅糟糕的技术啊。

继上一篇对浮点数的题目引发的思考，相信对浮点数潜在的取近似值导致的精度丢失问题都有所认识。那么，我们应该如何应对？

1. 尽量不使用浮点数。
   例如，需要保存币种时，总是以最小单位存储。像人民币，那就以分为单位存储。
2. 在需要使用浮点数时，推荐使用BigDecimal

   a. 不要使用BigDecimal(double)构造器，同样会存在近似值问题。推荐使用BigDecimal(String)
   b. BigDecimal在比较时，equals和compareTo是有区别的
   equals方法除了比较值，还会比较精度。因此即使值相等，精度不相等也是false
   而compareTo则只比较值大小。

1. 传统API非常不便利，例如Date进行运算比较麻烦。
	- 例如：在计算两个日期的时间间隔，没有直接的API。手动进行运算有两种方式：
	要么通过获取两个日期的毫秒相减再除以每天的毫秒数，这种只能精确到天。
	要么通过转换成Calendar然后用add方法来精确计算
	还有一种是，各种山寨的人工统一按照30天/365天计算月/年。
	与之对应的是，JDK8提供了新的Duration和Period可以很方便的计算。
2. 传统API的格式化线程不安全，推荐使用新API的DateTimeFormat

日期格式中，
M表示月份，而m表示的是分钟
H表示的是24小时制，h表示的是12小时。

避免系统中出现时间格式不统一。

public static final String[] DATA_TIME_PATTERNS = new String[] {
	"yyyy-MM-dd HH:mm:ss.SSS",
	"yyyy-MM-dd HH:mm:ss",
	"yyyy-MM-dd HH:mm",
	"yyyy-MM-dd"
}

1. 对null进行switch，可是会NPE的！！！因此需要先判空。
   原因是，对于封装类型或者String，要么自动拆箱，要么获取hashCode进行比较。而这两者都是直接调用的对象的方法。
2. switch中必须有且只有一个default，并且必须放在最后。
   原因是，如果没有default，那么异常情况就没得处理了。而如果不是在最后，要是没有break，真不知道执行到哪里才会停止！
3. 每个case都必须用break/return/continue等来终止，如果没有则必须注明在哪里终止。