为什么新出的《阿里Java开发手册》都要读一读？

本文主要是介绍为什么新出的《阿里Java开发手册》都要读一读？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

每次阿里新出Java开发手册，都会抽时间读一读。不仅如此，还会将最新的Idea插件更新一番，以规范开发。这个习惯养成很久了，以至于将Idea更新到最新版本时，发现阿里对应的插件还不能用，竟然有些懊恼升级了。

以铜为镜,可以正衣冠

在4月22日，阿里Java开发手册“泰山版”发行了。借此来专门聊聊这套开发手册。

唐太宗曾说：“以铜为镜,可以正衣冠”。阿里的这套开发手册可谓开发人员的镜子，而且是非常明亮的镜子。

在开发过程中，最容易犯错的地方其实是写的最顺手的代码，顺手到不用过脑子就写得出来。多年之后，自己也坚信这是最好优雅的代码。此时，一个高手看到你的代码，说代码有XX问题。此时才发现，几年了竟然没有人提醒……

而阅读这套开发手册及对应的IDE插件，就好像有那么一个高手时刻站在身旁，帮你审阅代码。特别是当你对提示有疑惑的时候，尝试去深入了解为什么的时候，也正是提升能力的时候。

再次阅读的收获

泰山版花了差不多三个小时，从头到尾阅读了一遍，收获颇丰。而且该版本对比华山版新增了34条新规约、修改了90处描述。下面以几个例子来说说学到内容或一些感悟。

第一条：【强制】类型与中括号紧挨相连来表示数组。比如定义整形数组int[] arrayDemo;。

为什么将这个作为第一条？因为最近写的《Java数组，这一篇文章就真够了！》中也提出相同的建议。没想到在阿里的手册中再次重逢，这种似曾相识的感觉很好，更容易加深记忆。

第二条：【强制】包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。正例:应用工具类包名为com.alibaba.ei.kunlun.aap.util、类名为MessageUtils(此规则参考 spring的框架结构)。

当读到这一条时，才发现之前在命名包的时候，特别是工具包的时候，一直在使用utils。虽然没什么影响，但这里提供了意外一个思路：可以写成util，而且在阿里要强制这么写。

第三条：【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。

其实这一条一直在践行，值得留意的是最后的推荐说明中提到JDK7引入的java.util.Objects#equals方法。看了一下源代码，发现使用该方法类判断更加严谨清晰明了，难怪阿里推荐。以后可以尝试使用了。

public static boolean equals(Object a, Object b) {return (a == b) || (a != null && a.equals(b));
}

第四条：所有整型包装类对象之间值的比较，全部使用equals方法比较。

这一条不过多解释（-128至127会复用已有对象值），而且相关的底层实现原理，在面试的过程中被问到的概率非常大。

第五条：【强制】任何货币金额，均以最小货币单位且整型类型来进行存储。

其实这一条是非常棒的约定，特别是针对金融行业，如果采用浮点类型（比如double）来存储，必定是一个很大的坑。

第六条：【强制】浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用equals来判断。

针对浮点类型的包装类不能用equals来判断，还真是第一次了解到。这么多年基本上都在金融行业，很少直接使用浮点类型，基本上都是直接采用BigDecimal来代替。

文档中也建议使用BigDecimal来代替。同时还提出了另外一个指定可接受范围的方式，又打开了一个新思路。“指定一个误差范围，两个浮点数的差值在此范围之内，则认为是相等的。”

float a = 1.0f - 0.9f;
float b = 0.9f - 0.8f;
float diff = 1e-6f;if (Math.abs(a - b) < diff) {   System.out.println("true");
}

第七条：【强制】禁止使用构造方法BigDecimal(double)的方式把double值转化为BigDecimal对象。BigDecimal(double)存在精度损失风险，在精确计算或值比较的场景中可能会导致业务逻辑异常。如:BigDecimal g = new BigDecimal(0.1f);实际的存储值为:0.10000000149。

这一项真的是第一次了解到，不文档不知道的。看来以后都直接使用字符串作为入参或使用valueOf方法来进行转换了。

第八条：【强制】判断所有集合内部的元素是否为空，使用isEmpty()方法，而不是size()==0的方式。说明:前者的时间复杂度为O(1)，而且可读性更好。

其实一直都在使用isEmpty()方法，但某一刻也在怀疑这样写的必要性，读到这里，给自己一个坚持写下去的理由。

第九条：【推荐】集合初始化时，指定集合初始值大小。说明:HashMap使用 HashMap(int initialCapacity)初始化，如果暂时无法确定集合大小，那么指定默认值(16)即可。

在一条也一直在践行，但每次遇到不能够确定大小的时候，就非常纠结，如果不写值，检查工具会提示。现在好了，内部实现默认是16，这里直接也写16，再也不用看到IDE的提示而纠结了。

第十条：【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据。说明:如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。

一直偏爱使用乐观锁，这里给出了明确的阈值和依据，以后更加有底气了。

第十一条：【推荐】资金相关的金融敏感信息，使用悲观锁策略。说明:乐观锁在获得锁的同时已经完成了更新操作，校验逻辑容易出现漏洞，另外，乐观锁对冲突的解决策略有较复杂的要求，处理不当容易造成系统压力或数据异常，所以资金相关的金融敏感信息不建议使用乐观锁更新。正例:悲观锁遵循一锁二判三更新四释放的原则。

一直从事金融行业，对资金的变动是十分敏感的，锁是必不可少的，没想到的是阿里直接建议使用悲观锁策略，来点用悲观锁的底气。

第十二条：【强制】在高并发场景中，避免使用”等于”判断作为中断或退出的条件。说明:如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件来代替。

说实话，如果没看到这一条，还真没留意。