HollisChuang's Blog很多人都知道，阿里巴巴在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 操作
