因为之前公司入职需要考试阿里巴巴规范（老板是阿里的）所以特定仔细看了一下华山版，发现有多个严重问题

1.5.1. 说明：String 已覆写 hashCode 和 equals 方法，所以我们可以愉快地使用 String 对象作为 key 来使用。 这句话本生没毛病，但有个前提，就是在业务开发上，string 作为 key 经常带来问题，千万别强行把应该是对象当 Key 的序列化成 String 当 key，我在我的博文里 https://my.oschina.net/xiandafu/blog/1514365 『警惕 String，数组，和 Map 』一节里说的比较清楚了。这篇文章是 2017 年写的，我后来 2019 年入职京东，曾经发生过一个 P0 故障，就是 Area 对象序列化成 String 作为 Map 的 Key 导致的。有兴趣可以看『https://www.kancloud.cn/xiandafu/javamicrotuning』 我的电子书第一章，里面详细描述了这个

1.6.3 线程资源必须通过线程池提供 线程必需要通过线程池来创建，不过这个规约的问题在于，线程池是谁来创建呢？ 规约并没有说明。如果创建线程池很随意，那岂不是创建线程也随意了。一般应用，都需要把常见线程池的代码集中管理，比如 Spring 应用，统一 xml 配置，或者一个 Configuration 类配置。避免人人都随便创建线程池。

1.6.11 并发修改同一记录时，避免更新丢失，需要加锁 关于应用层加锁，我想规约肯定是说的分布式锁。那么分布式如何加呢，分布式锁如何与事务搭配。规约并没有说清楚。一种错误使用是，在事务内使用分布式锁，当锁释放而事务还未提交，那么可能引起其他线程的脏读或者其他数据隔离错误。规约这一节说的并不是很详细。

1.9.7 不要在视图模板中加入任何复杂的逻辑 这句话忽略了『渲染逻辑』，模板中不可避免了有一定渲染逻辑。 规约应该纠正为 『不可加入复杂的业务逻辑』

2.1.9 在调用 RPC、二方包、或动态生成类的相关方法时，捕捉异常必须使用 Throwable 类来进行拦截 OutOfMemoryError 也是 Thowable 的子类，如果刚好出现这种错误，很容易被掩盖掉。我的建议还是正常捕获业务异常，统一处理这种预期外的异常。我曾解决一个系统不响应的问题，就是开发人员 catch Thowable 异常，然后正常日志告警，但这个异常刚好是 OutOfMemoryError。

2.1.5 有 try 块放到了事务代码中，catch 异常后，如果需要回滚事务，一定要注意手动回 滚事务 手动管理事务？搞错 Java 事务管理的方式了吧，一般都是标记回滚，而不是手动回滚。另外，如果按照这样的规约，一个复杂的应用里，到处都是 catch，到处是手动回滚，事务管理就混乱了。 直接在最外层回滚不简单么？

5.4.9 @Transactional 事务不要滥用 给出的理由是『事务会影响数据库的 QPS』，如果业务没有写数据，可以配置事务为 readonly。数据库操作都是自带事务的，很难想明白这句话的的意思是什么