因为之前公司入职需要考试阿里巴巴规范（老板是阿里的）所以特定仔细看了一下华山版，发现有多个严重问题
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。数据库操作都是自带事务的，很难想明白这句话的的意思是什么
没想到强如阿里，也会在公开发行的代码规范里有这些问题，欢迎讨论，欢迎从阿里Java代码规范里找到更多不合理的地方
?