阿里巴巴代码规范中的多个问题

原创
2021/07/08 15:00
阅读数 3.4K

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

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。数据库操作都是自带事务的,很难想明白这句话的的意思是什么

展开阅读全文
加载中
点击加入讨论🔥(2) 发布并加入讨论🔥
打赏
2 评论
0 收藏
3
分享
返回顶部
顶部