工程师对于代码，一定要精益求精，不论从性能，还是简洁优雅，都要具备精益求精的工匠精神，认真打磨自己的作品。
-- 多隆
上一篇：《泥瓦匠：品阿里 Java 开发手册有感（上）》
5. 并发处理
【书摘】第一，线程必须通过线程池来提供，不允许显式创建线程。第二，线程池不允许用 Executors 创建，应使用 ThreadPoolExecutor 去创建。因为 Executors 创建的几种 ThreadPool 会有弊端：
- FixedThreadPool 和 SingleThreadPool 允许请求队列长度为 Integer.MAX_VALUE ，大量请求，会导致 OOM
- CachedThreadPool 和 ScheduledThreadPool 允许创建最大的线程数为 Integer.MAX_VALUE，大量创建线程，会导致 OOM
所以，使用 ThreadPoolExecutor 的原因是能更好地理解线程池的运行规则，规避资源耗尽，更好地贴合某个业务场景，去创建更适合的线程池。
【书摘】在高并发场景中，同步调用应该考虑锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。即，加锁的粒度越小，性能损耗越小。并且避免锁的代码块中调用了 RPC 方法。
另外，同时对多个资源加锁的时候，需要保持一致的加锁顺序。否则，一个线程加锁顺序为 ABC,另一个加锁顺序为 ACB 或 BAC 等，会造成死锁。如图：
【书摘】金融资金相关信息，使用悲观锁。比如更新某个用户的钱包余额字段。
小思考：我以前做 P2P 的时候，就很简单地使用了 MySQL 的行锁。
具体行锁，表锁大家可以自行百度了解。
6. 控制语句
【书摘】高并发场景，比如秒杀场景，商品扣库存，库存的判断不要用“等于”来判断商品库存已售罄的条件。应使用大于或者小于的条件来代替。
小思考：这是典型的超卖场景。有人会问也会存在超卖几件的问题吧？答案是是的。但如果用 等于 来判断，超卖的件数会很多很多，比如达到 1 万件。但超卖 1 万件和超卖 1 件是不一样等级的故障。或者是一个故障和一个不是故障的区别。
7.异常处理
【书摘】异常不要用来做流程控制，条件控制
小思考：昨天京东小哥问我，这个能这么搞降级吗？如下代码：
这不算降级，这也不能这么搞。第一，代码这也写就不对，异常不要用来做流程控制，条件控制。第二，这个只要实现 ES 读取有问题，读取不到就读 DB。可以考虑责任链设计模式去实现。伪代码如下：
8. 建表规约 、SQL 语句
【书摘】当单表行数超过 500 万行或者单表容量超过 2 GB时，才推荐进行分库分表。
如果预计三年后的数量级无法达到这个级别，请不要在创建表时就分库分表。
【书摘】不要使用 count(列名) 或者 count(常量) 来替代 count(*)。 因为它是 SQL92 定义的标准统计行数的预发。它会统计 NULL 的行。
【书摘】where 条件下里面的 in 能避免就避免，要注意 in 里面的集合数量，控制在 1000 个之内。
【书摘】在代码中写分页查询，如果 count 为 0 ，直接返回 空列表。避免执行下面的分页语句。
9.服务器
【书摘】高并发服务器建议调小 TCP 协议的 time_wait 超时时间。Linux 修改 /etc/sysctl.conf 文件，代码如下：
【书摘】JVM 设置参数 -XX:+HeapDumpOnOutOfMemoryError。让 JVM 碰到 OOM 的时候，输出 dump 信息。
小思考：这个很重要。二者得保留事故服务器现场。比如 OOM 了某个服务器，则在 VIP 或者啥摘到该机器，让该机器不再有请求进入。然后去查看 dump 信息，去排查 OOM 问题。
最后
感谢小册子《阿里巴巴 Java 开发手册》，感觉不错。至少其中有几点，有目共睹的。
上一篇没看的可以看下：《泥瓦匠：品阿里 Java 开发手册有感（上）》
扫扫关注
✬如果你喜欢这篇文章，欢迎分享和点赞✬
