很多人都知道,阿里巴巴在2017发布了《阿里巴巴Java开发手册》,前后推出了很多个版本,并在后续推出了与之配套的IDEA插件和书籍。
相信很多Java开发都或多或少看过这份手册,这份手册有7个章节,覆盖了编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构以及设计规约等方面。
这份规约可以说是覆盖了Java开发的方方面面,如果还有人没看的话,强烈建议大家好好看看,并且仔细研读。
手册中,有那么一些规则,是比较容易理解的。比如一些变量命名规范,有另外一些规则,是不太容易理解的,背后是有很多思考的,有一些则是阿里这么多年来遇到的坑的总结。
这份手册在诞生之初,是在阿里内部的,那时候就引起了广泛的讨论。最终外界看到的那份手册,是阿里无数工程师”挑剔”后的结果,可以说是凝聚了无数工程师成功的经验、踩过的坑等。
其实,规约最大的价值,应该是促使人去思考规约制定背后的思考。真的去探查规约背后的原理,这个过程中可以学习到很多东西。
我写过几篇关于规约中部分规则的自己理解。这里面简单做个总结,这个系列并没有完结,我后面还会继续完善。
一、为什么阿里巴巴禁止工程师直接使用日志系统(Log4j、Logback)中的 API

在Java生态体系中,围绕着日志,有很多成熟的解决方案。关于日志输出,主要有两类工具。
一类是日志框架,主要用来进行日志的输出的,比如输出到哪个文件,日志格式如何等。 另外一类是日志门面,主要一套通用的API,用来屏蔽各个日志框架之间的差异的。
所以,对于Java工程师来说,关于日志工具的使用,最佳实践就是在应用中使用如Log4j + SLF4J 这样的组合来进行日志输出。
这样做的最大好处,就是业务层的开发不需要关心底层日志框架的实现及细节,在编码的时候也不需要考虑日后更换框架所带来的成本。这也是门面模式所带来的好处。
详解:为什么阿里巴巴禁止工程师直接使用日志系统(Log4j、Logback)中的 API
二、为什么阿里巴巴建议集合初始化时,指定集合容量大小?

HashMap有扩容机制,就是当达到扩容条件时会进行扩容。如果我们没有设置初始容量大小,随着元素的不断增加,HashMap会发生多次扩容,而HashMap中的扩容机制决定了每次扩容都需要重建hash表,是非常影响性能的。
默认情况下,当我们设置HashMap的初始化容量时,实际上HashMap会采用第一个大于该数值的2的幂作为初始化容量。
但是,为了最大程度的避免扩容带来的性能消耗,我们建议可以把默认容量的数字设置成expectedSize / 0.75F + 1.0F 。在日常开发中,可以使用
Map<String, String> map = Maps.newHashMapWithExpectedSize(10);
来创建一个HashMap,计算的过程guava会帮我们完成。
但是,以上的操作是一种用内存换性能的做法,真正使用的时候,要考虑到内存的影响。
详解:为什么阿里巴巴建议集合初始化时,指定集合容量大小?
三、为什么阿里巴巴禁止在 foreach 循环里进行元素的 remove/add 操作
