阿里Java规范读后总结

阿里Java规范读后总结

之前读了阿里的java规范，对一些眼前一亮的点总结一下。

• 不允许魔法值，这是经常出现的事…

• 在long或者Long赋值时，数值最后使用大写的L，不能是小写的l

• 在JDK7版本及以上，Comparator实现类要满足如下三个条件，不然Arrays.sort,Collections.sort会报IllegalArgumentException异常。

  1.x，y的比较结果和y, x的比较结果相反。

  2.x > y, y > z 则 x > z

  3.x = y, 则x, y的比较结果和y, z的比较结果相同。

• 高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。避免在锁代码块中调用RPC方法。

• 如果想获取更加精确的纳秒级时间值，使用System.nanoTime()的方式。在JDK8中，针对统计时间等场景，推荐使用Instant类。

• 并发修改同一条记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据。

  说明:如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于三次。

  乐观锁的实现:在表内新加一个version字段，一开始先查出记录，然后更新时加上where条件version需要等于之前查出的值，即如果version和之前相等才能更新。不成功则要重试。

  悲观锁的实现:一个完整的操作流程都需要加上锁，防止数据被其他事务修改，以下订单为例参考实现[悲观锁](! https://www.iteye.com/blog/chenzhou123520-1860954)

• 级联调用obj.getA().getB().getC()，一连串调用，易产生Null Point Exception；通过使用JDK8的[Optional类](! https://blog.rmiao.top/java-optional-usage-note/)来防止NPE问题。

• 多层条件语句建议使用卫语句、策略模式、状态模式等方式重构。状态模式

• 如果预计单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。

• 超过三个表禁止join。需要join的字段，数据类型必须绝对一致:多表关联查询时，保证被关联的字段需要有索引。

• 页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

• 在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

• 利用延迟关联或者子查询优化超多分页场景。

  SELECT a.* FROM 表1 a,(select id from 表1 where 条件 LIMIT 100000, 20) b where a.id = b.id。原理：尽可能地使用索引覆盖扫描，首先利用二级索引查出了id，再根据id(一级索引，聚簇索引)查出所需要的列。

• 当某一列的只全是NULL时，count(col)的返回结果为0，但sum(col)的返回结果为NULL，因此使用sum()时需要注意NPE问题。SELECT IF(ISNULL(SUM(G)),0,SUM(G)) FROM table;\

• POJO类的布尔属性不能加id，而数据库字段必须加is_，要求在resultMap中进行字段于属性的映射。