阿里java规范摘抄（个人认为对自己比较有用的地方留存）

1【强制】常量命名全部大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。
 正例： MAX_STOCK_COUNT
反例： MAX_COUNT
2【强制】中括号是数组类型的一部分，数组定义如下：String[] args;
反例：请勿使用 String args[]的方式来定义  
3【强制】POJO 类中的任何布尔类型的变量，都不要加 is，否则部分框架解析会引起序列化错
误。

4【强制】杜绝完全不规范的缩写，避免望文不知义。 （回到第一条上同样适用，应以表达明确为目的，不要嫌名字畅 condition“缩写”命名成
condi） 

5【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加），保持代码的简洁
性，并加上有效的 javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定是
与接口方法相关，并且是整个应用的基础常量。（之前一直从来没有主要到这一点。要注意改进）

6.接口和实现类的命名有两套规则：
1）【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部
的实现类用 Impl 的后缀与接口区别。 （这种模式不需要多说什么大部分都应该按照此种模式执行，另外一种如果是形容能力的接口名称，取对应的形容词做接口名（通常是–able 的形
式）。
正例：AbstractTranslator 实现 Translatable）
7各层命名规约： 领域模型命名规约  4） POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO（之前忘记是跟谁学的代码风格，习惯定义为POJO 实际上一般展示对象：xxxVO，xxx 一般为网页名称。 ） 
8【强制】不允许出现任何魔法值（即未经定义的常量）直接出现在代码中。
反例： String key="Id#taobao_"+tradeId；
    cache.put(key, value);
 
（这一点之前也从来不太注意到，一直以为这样书写写起来很方便，如果读代码逻辑时可以直接读下去，其实这种方式可读性更低，并且规范性特差）
9【强制】long 或者 Long 初始赋值时，必须使用大写的 L，不能是小写的 l，小写容易跟数字 1 混淆，造成误解。（这件事需要多加注意，之前并没有太在意这件事情上面）
10 【推荐】不要使用一个常量类维护所有常量，应该按常量功能进行归类，分开维护。如：缓存 相关的常量放在类：CacheConsts 下；系统配置相关的常量放在类：ConfigConsts 下。
说明：大而全的常量类，非得 ctrl+f 才定位到修改的常量，不利于理解，也不利于维护
11【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值

12.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中。
13.【强制】POJO 类必须写 toString 方法。使用工具类 source> generate toString 时，如果继
承了另一个 POJO 类，注意在前面加一下 super.toString。
说明：在方法执行抛出异常时，可以直接调用 POJO 的 toString()方法打印其属性值，便于排
查问题。
14. 【推荐】使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内 容的检查，否则会有抛 IndexOutOfBoundsException 的风险。
15【推荐】循环体内，字符串的联接方式，使用 StringBuilder 的 append 方法进行扩展  说明：反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，然后进行
append 操作，最后通过 toString 方法返回 String 对象，造成内存资源浪费。
 16【强制】使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，说明：asList 的返回对象是一个 Arrays 内部类，并没有实现集合的修改方法。Arrays.asList
体现的是适配器模式，只是转换接口，后台的数据仍是数组。
17. 【强制】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
说明：使用线程池的好处是减少在创建和销毁线程上所花的时间以及系统资源的开销，解决资
源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者
“过度切换”的问题
 18【强制】多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获 抛出的异常，其它任务便会自动终止运行，使用 ScheduledExecutorService 则没有这个问题。
19 【强制】线程池不允许使用 Executors 去创建，而是通过 ThreadPoolExecutor 的方式，这样
的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
说明：Executors 各个方法的弊端：
1）newFixedThreadPool 和 newSingleThreadExecutor:
  主要问题是堆积的请求处理队列可能会耗费非常大的内存，甚至 OOM。
2）newCachedThreadPool 和 newScheduledThreadPool:
  主要问题是线程数最大数是 Integer.MAX_VALUE，可能会创建数量非常多的线程，甚至 OOM 
20.【推荐】避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一 seed
导致的性能下降。
 21【推荐】推荐尽量少用 else， if-else 的方式可以改写成：
if(condition){              …             return obj;    }   // 接着写 else 的业务逻辑代码;  说明：如果使用要 if-else if-else 方式表达逻辑，【强制】请勿超过 3 层，超过请使用状态 设计模式。
  22极有可能被循环调用的方法，不建议对参数进行校验。但在方法说明里必须注明外部参
数检查。
 23对大段代码进行 try-catch，这是不负责任的表现。catch 时请分清稳定代码和非稳 定代码，稳定代码指的是无论如何不会出错的代码。对于非稳定代码的 catch 尽可能进行区分
异常类型，再做对应的异常处理。
24捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，如果不想处理它，请
将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户可以理解的
内容。
25不能在 finally 块中使用 return，finally 块中的 return 返回后方法结束执行，不 会再执行 try 块中的 return 语句
26表名不使用复数名词。
说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数
形式，符合表达习惯
27varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度
大于此值，定义字段类型为 TEXT，独立出来一张表，用主键来对应，避免影响其它字段索引
效率。
28超过三个表禁止 join。需要 join 的字段，数据类型保持绝对一致；多表关联查询时， 保证被关联的字段需要有索引。