无心间看到了公众号推送了一个阿里巴巴Java开发手册，内容很全，颇有参考价值，不愧为国内甚至是国际的领军企业。阅读这个手册除了能知道java的不少规范，摒弃本身以前的陋习以外，还能学到不少java的基础知识，这里笔者把它从PDF上搬上来，方便之后查阅。java
法律声明：本手册为阿里巴巴集团技术部的技术分享，版权归阿里巴巴集团全部，仅供你们交流、学习及研究使用，禁止用于商业用途，违者必究。 mysql
1、 编程规约
(一)命名规约
【强制】 代码中的命名均不能如下划线或美圆符号开始，也不能如下划线或美圆符号结束。 反例： _name / __name / $Object / name_ / name$ / Object$
【强制】 代码中的命名严禁使用拼音与英文混合的方式，更不容许直接使用中文的方式。 反例： 正例： alibaba / taobao / youku / hangzhou 等国际通用的名称， 可视同英文。
【强制】类名使用 UpperCamelCase 风格，必须听从驼峰形式，但如下情形例外： （领域模型的相关命名） DO / BO / DTO / VO 等。 正例： MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例：
【强制】方法名、参数名、成员变量、局部变量都统一使用 lowerCamelCase 风格，必须听从驼峰形式。 正例： localValue / getHttpMessage() / inputUserId
【强制】常量命名所有大写，单词间用下划线隔开，力求语义表达完整清楚，不要嫌名字长。 正例： MAX_STOCK_COUNT 反例：
【强制】抽象类命名使用 Abstract 或 Base 开头； 异常类命名使用 Exception 结尾； 测试类命名以它要测试的类的名称开始，以 Test 结尾。
【强制】中括号是数组类型的一部分，数组定义以下： String[] args; 反例：
【强制】 POJO 类中布尔类型的变量，都不要加 is，不然部分框架解析会引发序列化错误。 反例：
【强制】包名统一使用小写，点分隔符之间有且仅有一个天然语义的英语单词。包名统一使用单数形式，可是类名若是有复数含义，类名可使用复数形式。 正例： 应用工具类包名为 com.alibaba.open.util、类名为 MessageUtils（此规则参考spring 的框架结构）
【强制】杜绝彻底不规范的缩写， 避免望文不知义。 反例：
【推荐】若是使用到了设计模式，建议在类名中体现出具体模式。 正例：
public class OrderFactory ;public class LoginProxy ;public class ResourceObserver ;
【推荐】接口类中的方法和属性不要加任何修饰符号（public 也不要加） ，保持代码的简洁性，并加上有效的 Javadoc 注释。尽可能不要在接口里定义变量，若是必定要定义变量，确定是与接口方法相关，而且是整个应用的基础常量。 正例： 接口方法签名： void f(); 反例：
接口和实现类的命名有两套规则： 正例： CacheServiceImpl 实现 CacheService 接口。 正例： AbstractTranslator 实现 Translatable。
【参考】枚举类名建议带上 Enum 后缀，枚举成员名称须要全大写，单词间用下划线隔开。 正例： 枚举名字： DealStatusEnum， 成员名称： SUCCESS / UNKOWN_REASON。
【参考】各层命名规约：
(二)常量定义
【强制】不容许出现任何魔法值（即未经定义的常量） 直接出如今代码中。 反例：
【强制】 long 或者 Long 初始赋值时，必须使用大写的 L，不能是小写的 l，小写容易跟数字1 混淆，形成误解。
【推荐】不要使用一个常量类维护全部常量，应该按常量功能进行归类，分开维护。如：缓存相关的常量放在类： CacheConsts 下； 系统配置相关的常量放在类： ConfigConsts 下。
【推荐】常量的复用层次有五层：跨应用共享常量、应用内共享常量、子工程内共享常量、包内共享常量、类内共享常量。 反例：
【推荐】若是变量值仅在一个范围内变化用 Enum 类。若是还带有名称以外的延伸属性，必须使用 Enum 类，下面正例中的数字就是延伸信息，表示星期几。 正例： public Enum{ MONDAY(1), TUESDAY(2), WEDNESDAY(3), THURSDAY(4), FRIDAY(5),SATURDAY(6), SUNDAY(7);}
(三)格式规约
【强制】大括号的使用约定。若是是大括号内为空，则简洁地写成{}便可，不须要换行； 若是是非空代码块则：
【强制】 左括号和后一个字符之间不出现空格； 一样，右括号和前一个字符之间也不出现空格。详见第 5 条下方正例提示。
【强制】 if/for/while/switch/do 等保留字与左右括号之间都必须加空格。
【强制】任何运算符左右必须加一个空格。
【强制】 缩进采用 4 个空格，禁止使用 tab 字符。 正例： （涉及 1-5 点）
public static void main (String args[]) {
String say = "hello" ;
int flag = 0 ;
if (flag == 0 ) {
System.out.println(say);
}
if (flag == 1 ) {
System.out.println("world" );
} else {
System.out.println("ok" );
}
}
【强制】单行字符数限制不超过 120 个，超出须要换行，换行时遵循以下原则： 正例：
StringBuffer sb = new StringBuffer();
sb.append("zi" ).append("xin" )...
.append("huang" )...
.append("huang" )...
.append("huang" );
***反例：***
StringBuffer sb = new StringBuffer();
sb.append("zi" ).append("xin" )...append
("huang" );
method(args1, args2, args3, ...
, argsX);
【强制】方法参数在定义和传入时，多个参数逗号后边必须加空格。 正例： 下例中实参的”a”,后边必需要有一个空格。
【强制】 IDE 的 text file encoding 设置为 UTF-8; IDE 中文件的换行符使用 Unix 格式，不要使用 windows 格式。
【推荐】没有必要增长若干空格来使某一行的字符与上一行的相应字符对齐。 正例：
int a = 3 ;
long b = 4 L;
float c = 5 F;
StringBuffer sb = new StringBuffer();说明： 增长 sb 这个变量，若是须要对齐，则给 a、 b、 c 都要增长几个空格，在变量比较多的状况下，是一种累赘的事情。 linux
(四)OOP 规约
【强制】避免经过一个类的对象引用访问此类的静态变量或静态方法，无谓增长编译器解析成本，直接用类名来访问便可。
【强制】全部的覆写方法，必须加@Override 注解。 反例：
【强制】相同参数类型，相同业务含义，才可使用 Java 的可变参数，避免使用 Object。 正例： public User getUsers(String type, Integer… ids)
【强制】对外暴露的接口签名，原则上不容许修改方法签名，避免对接口调用方产生影响。接口过期必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。
【强制】不能使用过期的类或方法。
【强制】 Object 的 equals 方法容易抛空指针异常，应使用常量或肯定有值的对象来调用 正例： “test”.equals(object); 反例：
【强制】全部的相同类型的包装类对象之间值的比较，所有使用 equals 方法比较。
【强制】关于基本数据类型与包装数据类型的使用标准以下： 正例： 数据库的查询结果多是 null，由于自动拆箱，用基本数据类型接收有 NPE 风险。 反例：
【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。 反例：
【强制】序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败； 若是彻底不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值。
【强制】构造方法里面禁止加入任何业务逻辑，若是有初始化逻辑，请放在 init 方法中。
【强制】 POJO 类必须写 toString 方法。使用 IDE 的中工具： source> generate toString时，若是继承了另外一个 POJO 类，注意在前面加一下 super.toString。
【推荐】使用索引访问用 String 的 split 方法获得的数组时，需作最后一个分隔符后有无内容的检查，不然会有抛 IndexOutOfBoundsException 的风险。
String str = "a,b,c,," ;
String[] ary = str.split("," );
System.out.println(ary.length);
【推荐】当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一块儿，便于阅读。
【推荐】 类内方法定义顺序依次是：公有方法或保护方法 > 私有方法 > getter/setter方法。
【推荐】 setter 方法中，参数名称与类成员变量名称一致， this.成员名=参数名。在getter/setter 方法中，尽可能不要增长业务逻辑，增长排查问题的难度。 反例：
public Integer getData (){
if (true ) {
return data + 100 ;
} else {
return data - 100 ;
}
}
【推荐】循环体内，字符串的联接方式，使用 StringBuilder 的 append 方法进行扩展。 反例：
String str = "start" ;
for (int i=0 ; i<100 ; i++){
str = str + "hello" ;
}
说明： 反编译出的字节码文件显示每次循环都会 new 出一个 StringBuilder 对象，而后进行append 操做，最后经过 toString 方法返回 String 对象，形成内存资源浪费。 程序员
(五)集合处理
【强制】 关于 hashCode 和 equals 的处理，遵循以下规则： 正例： String 重写了 hashCode 和 equals 方法，因此咱们能够很是愉快地使用 String 对象做为 key 来使用。
【强制】 ArrayList的subList结果不可强转成ArrayList，不然会抛出 ClassCastException异常： java.util.RandomAccessSubList cannot be cast to java.util.ArrayList ;
【强制】 在 subList 场景中， 高度注意对原集合元素个数的修改，会致使子列表的遍历、增长、删除均产生 ConcurrentModificationException 异常。
【强制】使用集合转数组的方法，必须使用集合的 toArray(T[] array)，传入的是类型彻底同样的数组，大小就是 list.size()。 反例： 正例：
List<String> list = new ArrayList<String>(2 );
list.add("guan" );
list.add("bao" );
String[] array = new String[list.size()];
array = list.toArray(array);
说明： 使用 toArray 带参方法，入参分配的数组空间不够大时， toArray 方法内部将从新分配内存空间，并返回新数组地址； 若是数组元素大于实际所需，下标为[ list.size() ]的数组元素将被置为 null，其它数组元素保持原值，所以最好将方法入参数组大小定义与集合元素个数一致。 <? extends T>来接收返回的数据，此写法的泛型集合不能使用 add 方法。 <? extends Fruits>对象，此对象就不能往里加任何水果，包括苹果。 反例： web
List<String> a = new ArrayList<String>();
a.add("1" );
a.add("2" );
for (String temp : a) {
if ("1" .equals(temp)){
a.remove(temp);
}
}
说明： 以上代码的执行结果确定会出乎你们的意料，那么试一下把“1”换成“2”，会是一样的结果吗？ 正例： 正则表达式
Iterator<String> it = a.iterator();
while (it.hasNext()){
String temp = it.next();
if (删除元素的条件){
it.remove();
}
}
【强制】 在 JDK7 版本以上， Comparator 要知足自反性，传递性，对称性，否则 Arrays.sort，Collections.sort 会报 IllegalArgumentException 异常。 反例：
new Comparator<Student>() {
@Override
public int compare (Student o1, Student o2) {
return o1.getId() > o2.getId() ? 1 : -1 ;
}
}
【推荐】集合初始化时，尽可能指定集合初始值大小。
【推荐】使用 entrySet 遍历 Map 类集合 KV，而不是 keySet 方式进行遍历。 正例： values()返回的是 V 值集合，是一个 list 集合对象； keySet()返回的是 K 值集合，是一个 Set 集合对象； entrySet()返回的是 K-V 值组合集合。
【推荐】高度注意 Map 类集合 K/V 能不能存储 null 值的状况，以下表格： 反例：
【参考】合理利用好集合的有序性(sort)和稳定性(order)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。
【参考】利用 Set 元素惟一的特性，能够快速对一个集合进行去重操做，避免使用 List 的contains 方法进行遍历、对比、 去重操做。
(六)并发处理
【强制】 获取单例对象须要保证线程安全，其中的方法也要保证线程安全。
【强制】建立线程或线程池时请指定有意义的线程名称，方便出错时回溯。 正例：
public class TimerTaskThread extends Thread {public TimerTaskThread (){
super .setName("TimerTaskThread" ); ...
}
【强制】线程资源必须经过线程池提供，不容许在应用中自行显式建立线程。
【强制】线程池不容许使用 Executors 去建立，而是经过 ThreadPoolExecutor 的方式，这样的处理方式让写的同窗更加明确线程池的运行规则，规避资源耗尽的风险。
【强制】 SimpleDateFormat 是线程不安全的类，通常不要定义为 static 变量，若是定义为static，必须加锁，或者使用 DateUtils 工具类。 正例： 注意线程安全，使用 DateUtils。亦推荐以下处理：
private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
@Override
protected DateFormat initialValue () {
return new SimpleDateFormat("yyyy-MM-dd" );
}
};说明： 若是是 JDK8 的应用，可使用 Instant 代替 Date， LocalDateTime 代替 Calendar， 正例： 在 JDK7 以后，能够直接使用 API ThreadLocalRandom，在 JDK7 以前，能够作到每一个线程一个实例。 反例： spring
class Foo {
private Helper helper = null ;
public Helper getHelper () {
if (helper == null ) synchronized (this ) {
if (helper == null )
helper = new Helper();
}
return helper;
}
}
【参考】 volatile 解决多线程内存不可见问题。对于一写多读，是能够解决变量同步问题，可是若是多写，一样没法解决线程安全问题。若是是 count++操做，使用以下类实现：
【参考】 HashMap 在容量不够进行 resize 时因为高并发可能出现死链，致使 CPU 飙升，在开发过程当中注意规避此风险。
【参考】 ThreadLocal 没法解决共享对象的更新问题， ThreadLocal 对象建议使用 static修饰。这个变量是针对一个线程内全部操做共有的，因此设置为静态变量，全部此类实例共享此静态变量 ，也就是说在类第一次被使用时装载，只分配一块存储空间，全部此类的对象(只要是这个线程内定义的)均可以操控这个变量。
(七)控制语句
【强制】在一个 switch 块内，每一个 case 要么经过 break/return 等来终止，要么注释说明程序将继续执行到哪个 case 为止； 在一个 switch 块内，都必须包含一个 default 语句而且放在最后，即便它什么代码也没有。
【强制】在 if/else/for/while/do 语句中必须使用大括号，即便只有一行代码，避免使用下面的形式： if (condition) statements;
【推荐】推荐尽可能少用 else， if-else 的方式能够改写成：
if (condition){
...
return obj;
}// 接着写 else 的业务逻辑代码; 正例： 逻辑上超过 3 层的 if-else 代码可使用卫语句，或者状态模式来实现。 正例： sql
boolean existed = (file.open(fileName, "w" ) != null ) && (...) || (...);
if (existed) {
...
}
***反例：***
if ((file.open(fileName, "w" ) != null ) && (...) || (...)) {
...
}
【推荐】循环体中的语句要考量性能，如下操做尽可能移至循环体外处理，如定义对象、变量、获取数据库链接，进行没必要要的 try-catch 操做（这个 try-catch 是否能够移至循环体外） 。
【推荐】接口入参保护，这种场景常见的是用于作批量操做的接口。
【参考】方法中须要进行参数校验的场景：
【参考】方法中不须要参数校验的场景：
(八)注释规约
【强制】 类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容 /格式，不得使用//xxx 方式。
【强制】全部的抽象方法（包括接口中的方法） 必需要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法作什么事情，实现什么功能。
【强制】全部的类都必须添加建立者信息。
【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。
【强制】全部的枚举类型字段必需要有注释，说明每一个数据项的用途。
【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文便可。 反例：
【推荐】代码修改的同时，注释也要进行相应的修改，尤为是参数、返回值、异常、核心逻辑等的修改。
【参考】注释掉的代码尽可能要配合说明，而不是简单的注释掉。
【参考】对于注释的要求：第1、可以准确反应设计思想和代码逻辑； 第2、可以描述业务含义，使别的程序员可以迅速了解到代码背后的信息。彻底没有注释的大段代码对于阅读者形同天书，注释是给本身看的，即便隔很长时间，也能清晰理解当时的思路； 注释也是给继任者看的，使其可以快速接替本身的工做。
【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是至关大的负担。 反例：
【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，经过标记扫描，常常清理此类标记。线上故障有时候就是来源于这些标记处的代码。
(九)其它
【强制】在使用正则表达式时，利用好其预编译功能，能够有效加快正则匹配速度。
【强制】 velocity 调用 POJO 类的属性时，建议直接使用属性名取值便可，模板引擎会自动按规范调用 POJO 的 getXxx()，若是是 boolean 基本数据类型变量（boolean 命名不须要加 is前缀） ，会自动调用 isXxx()方法。
【强制】后台输送给页面的变量必须加
! v a r — — 中 间 的 感 叹 号 。 说 明 ： 如 果 v a r = n u l l 或 者 不 存 在 ， 那 么 {var}会直接显示在页面上。
【强制】注意 Math.random() 这个方法返回是 double 类型，注意取值的范围 0≤x<1（可以取到零值，注意除零异常） ，若是想获取整数类型的随机数，不要将 x 放大 10 的若干倍而后取整，直接使用 Random 对象的 nextInt 或者 nextLong 方法。
【强制】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();
【推荐】尽可能不要在 vm 中加入变量声明、逻辑运算符，更不要在 vm 模板中加入任何复杂的逻辑。
【推荐】 任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增加吃光内存。
【推荐】对于“明确中止使用的代码和配置”，如方法、变量、类、配置文件、动态配置属性等要坚定从程序中清理出去，避免形成过多垃圾。
2、异常日志
(一)异常处理
【强制】不要捕获 Java 类库中定义的继承自 RuntimeException 的运行时异常类，如：IndexOutOfBoundsException / NullPointerException，这类异常由程序员预检查来规避，保证程序健壮性。 正例： if(obj != null) {…} 反例：
【强制】异常不要用来作流程控制，条件控制，由于异常的处理效率比条件分支低。
【强制】对大段代码进行 try-catch，这是不负责任的表现。 catch 时请分清稳定代码和非稳定代码，稳定代码指的是不管如何不会出错的代码。对于非稳定代码的 catch 尽量进行区分异常类型，再作对应的异常处理。
【强制】捕获异常是为了处理它，不要捕获了却什么都不处理而抛弃之，若是不想处理它，请将该异常抛给它的调用者。最外层的业务使用者，必须处理异常，将其转化为用户能够理解的内容。
【强制】有 try 块放到了事务代码中， catch 异常后，若是须要回滚事务，必定要注意手动回滚事务。
【强制】 finally 块必须对资源对象、流对象进行关闭，有异常也要作 try-catch。
【强制】不能在 finally 块中使用 return， finally 块中的 return 返回后方法结束执行，不会再执行 try 块中的 return 语句。
【强制】捕获异常与抛异常，必须是彻底匹配，或者捕获异常是抛异常的父类。
【推荐】方法的返回值能够为 null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么状况下会返回 null 值。调用方须要进行 null 判断防止 NPE 问题。
【推荐】防止 NPE，是程序员的基本修养，注意 NPE 产生的场景： 反例：
【推荐】在代码中使用“抛异常”仍是“返回错误码”，对于公司外的 http/api 开放接口必须使用“错误码”； 而应用内部推荐异常抛出； 跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess、 “错误码”、 “错误简短信息”。
【推荐】定义时区分 unchecked / checked 异常，避免直接使用 RuntimeException 抛出，更不容许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定义
【参考】避免出现重复的代码（Don’t Repeat Yourself） ，即 DRY 原则。 正例： 一个类中有多个 public 方法，都须要进行数行相同的参数校验操做，这个时候请抽取：private boolean checkParam(DTO dto){…}
(二)日志规约
【强制】应用中不可直接使用日志系统（Log4j、 Logback） 中的 API，而应依赖使用日志框架SLF4J 中的 API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。
【强制】日志文件推荐至少保存 15 天，由于有些异常具有以“周”为频次发生的特色。
【强制】应用中的扩展日志（如打点、临时监控、访问日志等） 命名方式： 正例： mppserver 应用中单独监控时区转换异常，如：
【强制】对 trace/debug/info 级别的日志输出，必须使用条件输出形式或者使用占位符的方式。 正例： （条件） 正例： （占位符）
【强制】避免重复打印日志，浪费磁盘空间，务必在 log4j.xml 中设置 additivity=false。 正例：
【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。若是不处理，那么往上抛。 正例： logger.error(各种参数或者对象 toString + “_” + e.getMessage(), e);
【推荐】可使用 warn 日志级别来记录用户输入参数错误的状况，避免用户投诉时，无所适从。注意日志输出的级别， error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要，请不要在此场景打出 error 级别。
【推荐】谨慎地记录日志。生产环境禁止输出 debug 日志； 有选择地输出 info 日志； 若是使用 warn 来记录刚上线时的业务行为信息，必定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。
3、 MySQL 规约
(一)建表规约
【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint（1 表示是， 0 表示否） ，此规则一样适用于 odps 建表。
【强制】表名、字段名必须使用小写字母或数字； 禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，由于没法进行预发布，因此字段名称须要慎重考虑。 正例： getter_admin， task_config， level3_name 反例：
【强制】表名不使用复数名词。
【强制】禁用保留字，如 desc、 range、 match、 delayed 等， 请参考 MySQL 官方保留字。
【强制】惟一索引名为 uk_字段名； 普通索引名则为 idx_字段名。
【强制】小数类型为 decimal，禁止使用 float 和 double。
【强制】若是存储的字符串长度几乎相等，使用 char 定长字符串类型。
【强制】 varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，若是存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
【强制】表必备三字段： id, gmt_create, gmt_modified。
【推荐】表的命名最好是加上“业务名称_表的做用”。 正例： tiger_task / tiger_reader / mpp_config
【推荐】库名与应用名称尽可能一致。
【推荐】若是修改字段含义或对字段表示的状态追加时，须要及时更新字段注释。
【推荐】字段容许适当冗余，以提升性能，可是必须考虑数据同步的状况。冗余字段应遵循： 正例： 商品类目名称使用频率高， 字段长度短，名称基本一成不变， 可在相关联的表中冗余存储类目名称，避免关联查询。
【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。
【参考】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提高检索速度。 正例： 人的年龄用 unsigned tinyint（表示范围 0-255，人的寿命不会超过 255 岁）； 海龟就必须是 smallint，但若是是太阳的年龄，就必须是 int； 若是是全部恒星的年龄都加起来，那么就必须使用bigint。
(二)索引规约
【强制】业务上具备惟一特性的字段，即便是组合字段，也必须建成惟一索引。
【强制】 超过三个表禁止 join。须要 join 的字段，数据类型保持绝对一致； 多表关联查询时，保证被关联的字段须要有索引。
【强制】在 varchar 字段上创建索引时，必须指定索引长度，不必对全字段创建索引，根据实际文本区分度决定索引长度。
【强制】页面搜索严禁左模糊或者全模糊，若是须要请走搜索引擎来解决。
【推荐】若是有 order by 的场景，请注意利用索引的有序性。 order by 最后的字段是组合索引的一部分，而且放在索引组合顺序的最后，避免出现 file_sort 的状况，影响查询性能。 正例： where a=? and b=? order by c; 索引： a_b_c 反例：
【推荐】利用覆盖索引来进行查询操做，来避免回表操做。 正例： 可以创建索引的种类：主键索引、惟一索引、普通索引，而覆盖索引是一种查询的一种效果，用 explain 的结果， extra 列会出现： using index。
【推荐】利用延迟关联或者子查询优化超多分页场景。 正例： 先快速定位须要获取的 id 段，而后再关联：
【推荐】 SQL 性能优化的目标：至少要达到 range 级别， 要求是 ref 级别， 若是能够是 consts 反例：
【推荐】建组合索引的时候，区分度最高的在最左边。 正例： 若是 where a=? and b=? ， a 列的几乎接近于惟一值，那么只须要单建 idx_a 索引便可。
【参考】建立索引时避免有以下极端误解：
(三)SQL 规约
【强制】不要使用 count(列名)或 count(常量)来替代 count()， count( )就是 SQL92 定义的标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。
【强制】 count(distinct col) 计算该列除 NULL 以外的不重复数量。注意 count(distinct col1, col2) 若是其中一列全为 NULL，那么即便另外一列有不一样的值，也返回为 0。
【强制】当某一列的值全是 NULL 时， count(col)的返回结果为 0，但 sum(col)的返回结果为NULL，所以使用 sum()时需注意 NPE 问题。 正例： 可使用以下方式来避免 sum 的 NPE 问题： SELECT IF(ISNULL(SUM(g)),0,SUM(g)) FROM table;
【强制】使用 ISNULL()来判断是否为 NULL 值。注意： NULL 与任何值的直接比较都为 NULL。
【强制】 在代码中写分页查询逻辑时，若 count 为 0 应直接返回，避免执行后面的分页语句。
【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
【强制】数据订正时，删除和修改记录时，要先 select，避免出现误删除，确认无误才能执
【推荐】 in 操做能避免则避免，若实在避免不了，须要仔细评估 in 后边的集合元素数量，控
【参考】 若是有全球化须要，全部的字符存储与表示，均以 utf-8 编码，那么字符计数方法
【参考】 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE无事务且不触发 trigger，有可能形成事故，故不建议在开发代码中使用此语句。
(四)ORM 规约
【强制】在表查询中，一概不要使用 * 做为查询的字段列表，须要哪些字段必须明确写明。
【强制】 POJO 类的 boolean 属性不能加 is，而数据库字段必须加 is_，要求在 resultMap 中进行字段与属性之间的映射。
【强制】不要用 resultClass 当返回参数，即便全部类属性名与数据库字段一一对应，也须要定义； 反过来，每个表也必然有一个与之对应。
【强制】 xml 配置中参数注意使用： #{}， #param# 不要使用${} 此种方式容易出现 SQL 注入。
【强制】 iBATIS 自带的 queryForList(String statementName,int start,int size)不推 正例： 在 sqlmap.xml 中引入 #start#, #size#
Map<String, Object> map = new HashMap<String, Object>();
map.put("start" , start);
map.put("size" , size);
【强制】不容许直接拿 HashMap 与 Hashtable 做为查询结果集的输出。
【强制】更新数据表记录时，必须同时更新记录对应的 gmt_modified 字段值为当前时间。
【推荐】不要写一个大而全的数据更新接口，传入为 POJO 类，无论是否是本身的目标更新字段，都进行 update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行 SQL时，尽可能不要更新无改动的字段，一是易出错； 二是效率低； 三是 binlog 增长存储。
【参考】 @Transactional 事务不要滥用。事务会影响数据库的 QPS，另外使用事务的地方须要考虑各方面的回滚方案，包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
【参考】 中的 compareValue 是与属性值对比的常量，通常是数字，表示相等时带上此条件； 表示不为空且不为 null 时执行； 表示不为 null 值时
4、工程规约
(一)应用分层
【推荐】图中默认上层依赖于下层，箭头关系表示可直接依赖，如：开放接口层能够依赖于Web 层，也能够直接依赖于 Service 层，依此类推：
【参考】 （分层异常处理规约） 在 DAO 层，产生的异常类型有不少，没法用细粒度异常进行catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不须要打印日志，由于日志在Manager/Service 层必定须要捕获并打到日志文件中去，若是同台服务器再打日志，浪费性能和存储。在 Service 层出现异常时，必须记录日志信息到磁盘，尽量带上参数信息，至关于保护案发现场。若是Manager 层与 Service 同机部署，日志方式与 DAO 层处理一致，若是是单独部署，则采用与 Service 一致的处理方式。Web 层毫不应该继续往上抛异常，由于已经处于顶层，无继续处理异常的方式，若是意识到这个异常将致使页面没法正常渲染，那么就应该直接跳转到友好错误页面，尽可能加上友好的错误提示信息。开放接口层要将异常处理成错误码和错误信息方式返回。
【参考】分层领域模型规约：
(二)二方库规约
【强制】定义 GAV 听从如下规则： 正例： com.taobao.jstorm 或 com.alibaba.dubbo.register 正例： dubbo-client / fastjson-api / jstorm-tool
【强制】二方库版本号命名方式：主版本号.次版本号.修订号
【强制】线上应用不要依赖 SNAPSHOT 版本（安全包除外）； 正式发布的类库必须使用 RELEASE版本号升级+1 的方式，且版本号不容许覆盖升级，必须去中央仓库进行查证。
【强制】二方库的新增或升级，保持除功能点以外的其它 jar 包仲裁结果不变。若是有改变，必须明确评估和验证， 建议进行 dependency:resolve 先后信息比对，若是仲裁结果彻底不一致，那么经过 dependency:tree 命令，找出差别点，进行排除 jar 包。
【强制】二方库里能够定义枚举类型，参数可使用枚举类型，可是接口返回值不容许使用枚举类型或者包含枚举类型的 POJO 对象。
【强制】依赖于一个二方库群时，必须定义一个统一版本变量， 避免版本号不一致。
【强制】禁止在子项目的 pom 依赖中出现相同的 GroupId，相同的 ArtifactId，可是不一样的Version。
【推荐】全部 pom 文件中的依赖声明放在语句块中，全部版本仲裁放在语句块中。
【推荐】二方库尽可能不要有配置项，最低限度不要再增长配置项。
【参考】为避免应用二方库的依赖冲突问题，二方库发布者应当遵循如下原则：
(三)服务器规约
【推荐】 高并发服务器建议调小 TCP 协议的 time_wait 超时时间。 正例： 在 linux 服务器上请经过变动/etc/sysctl.conf 文件去修改该缺省值（秒） ：
【推荐】 调大服务器所支持的最大文件句柄数（File Descriptor，简写为 fd） 。
【推荐】给 JVM 设置-XX:+HeapDumpOnOutOfMemoryError 参数，让 JVM 碰到 OOM 场景时输出dump 信息。
【参考】服务器内部重定向使用 forward； 外部重定向地址使用 URL 拼装工具类来生成， 不然会带来 URL 维护不一致的问题和潜在的安全风险。
5、安全规约
【强制】 隶属于用户我的的页面或者功能必须进行权限控制校验。
【强制】用户敏感数据禁止直接展现，必须对展现数据脱敏。
【强制】用户输入的 SQL 参数严格使用参数绑定或者 METADATA 字段值限定，防止 SQL 注入，禁止字符串拼接 SQL 访问数据库。
【强制】用户请求传入的任何参数必须作有效性验证。
【强制】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。
【强制】表单、 AJAX 提交必须执行 CSRF 安全过滤。
【强制】在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放限制，如数量限制、疲劳度控制、验证码校验，避免被滥刷、资损。
【推荐】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过滤等风控策略。 法律声明：本手册为阿里巴巴集团技术部的技术分享，版权归阿里巴巴集团全部，仅供你们交流、学习及研究使用，禁止用于商业用途，违者必究。