【阿里巴巴Java开发手册1.5】笔记

本篇博文记录的是我阅读【阿里巴巴Java开发手册1.5】后，对于重点知识的记录与部分分析

8.【强制】POJO类中布尔类型变量都不要加is前缀，否则部分框架解析会引起序列化错误。

9.【强制】包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。

15.【推荐】接口类中的方法和属性不要加任何修饰符号(public 也不要加)，保持代码的简洁 性，并加上有效的 Javadoc 注释。尽量不要在接口里定义变量，如果一定要定义变量，肯定 是与接口方法相关，并且是整个应用的基础常量

16.接口和实现类的命名有两套规则:

• 1)【强制】对于 Service 和 DAO 类，基于 SOA 的理念，暴露出来的服务一定是接口，内部的实现类用
  Impl 的后缀与接口区别。

• 2)【推荐】如果是形容能力的接口名称，取对应的形容词为接口名(通常是–able 的形容词)。

18.【参考】各层命名规约:

• A) Service/DAO 层方法命名规约
  1) 获取单个对象的方法用 get 做前缀。
  2) 获取多个对象的方法用 list 做前缀，复数形式结尾如:listObjects。
  3) 获取统计值的方法用 count 做前缀。
  4) 插入的方法用 save/insert 做前缀。
  5) 删除的方法用 remove/delete 做前缀。
  6) 修改的方法用 update 做前缀。
• B) 领域模型命名规约
  1) 数据对象:xxxDO，xxx 即为数据表名。
  2) 数据传输对象:xxxDTO，xxx 为业务领域相关的名称。
  3) 展示对象:xxxVO，xxx 一般为网页名称。
  4) POJO 是 DO/DTO/BO/VO 的统称，禁止命名成 xxxPOJO。

1.【强制】不允许任何魔法值(即未经预先定义的常量)直接出现在代码中

5.【推荐】如果变量值仅在一个固定范围内变化用enum类型来定义

6.【强制】注释的双斜线与注释内容之间有且仅有一个空格

8.【强制】单行字符数限制不超过120个，超出需要换行，换行时遵循如下原则:

1)第二行相对第一行缩进 4 个空格，从第三行开始，不再继续缩进，参考示例。
2)运算符与下文一起换行。
3)方法调用的点符号与下文一起换行。
4)方法调用中的多个参数需要换行时，在逗号后进行。
5)在括号前不要换行

OOP规约

4.【强制】外部正在调用或者二方库依赖的接口，不允许修改方法签名，避免对接口调用方产 生影响。接口过时必须加@Deprecated 注解，并清晰地说明采用的新接口或者新服务是什么。

6.【强制】Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用 equals。

正例:"test".equals(object);

7.【强制】所有整型包装类对象之间值的比较，全部使用equals方法比较

8.【强制】浮点数之间的等值判断，基本数据类型不能用==来比较，包装数据类型不能用
equals 来判断

说明:浮点数采用“尾数+阶码”的编码方式，类似于科学计数法的“有效数字+指数”的表示方式。

float a = 1.0f - 0.9f;
float b = 0.9f - 0.8f;
if (a == b) {
// 预期进入此代码快，执行其它业务逻辑
// 但事实上 a==b 的结果为 false
}
Float x = Float.valueOf(a);
Float y = Float.valueOf(b);
if (x.equals(y)) {
// 预期进入此代码快，执行其它业务逻辑
// 但事实上 equals 的结果为 false
}

(1) 指定一个误差范围，两个浮点数的差值在此范围之内，则认为是相等的。

float a = 1.0f - 0.9f;
float b = 0.9f - 0.8f;
float diff = 1e-6f;
if (Math.abs(a - b) < diff) {
    System.out.println("true");
}

(2) 使用 BigDecimal 来定义值，再进行浮点数的运算操作。

BigDecimal a = new BigDecimal("1.0");
BigDecimal b = new BigDecimal("0.9");
BigDecimal c = new BigDecimal("0.8");
BigDecimal x = a.subtract(b);
BigDecimal y = b.subtract(c);
if (x.equals(y)) {
    System.out.println("true");
}

9.【强制】定义数据对象DO类时，属性类型要与数据库字段类型相匹配。

正例:数据库字段的 bigint 必须与类属性的 Long 类型相对应

10.【强制】为了防止精度损失，禁止使用构造方法 BigDecimal(double)的方式把 double 值转 化为 BigDecimal 对象

11.关于基本数据类型与包装数据类型的使用标准如下:

1) 【强制】所有的 POJO 类属性必须使用包装数据类型。
2) 【强制】RPC 方法的返回值和参数必须使用包装数据类型。
3) 【推荐】所有的局部变量使用基本数据类型

12.【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值

13.【强制】序列化类新增属性时，请不要修改 serialVersionUID 字段，避免反序列失败;如果 完全不兼容升级，避免反序列化混乱，那么请修改 serialVersionUID 值

14.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在 init 方法中

15.【强制】POJO 类必须写 toString 方法。使用 IDE 中的工具:source> generate toString 时，如果继承了另一个 POJO 类，注意在前面加一下 super.toString

17.【推荐】使用索引访问用 String 的 split 方法得到的数组时，需做最后一个分隔符后有无内
容的检查，否则会有抛 IndexOutOfBoundsException 的风险

String str = "a,b,c,,";
String[] ary = str.split(",");
// 预期大于 3，结果是 3
System.out.println(ary.length);

19.【推荐】类内方法定义的顺序依次是:公有方法或保护方法 > 私有方法 > getter / setter 方法。

21.【推荐】循环体内，字符串的连接方式，使用 StringBuilder 的 append 方法进行扩展。

22.【推荐】final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字:

1) 不允许被继承的类，如:String 类。
2) 不允许修改引用的域对象。
3) 不允许被覆写的方法，如:POJO 类的 setter 方法。
4) 不允许运行过程中重新赋值的局部变量。
5) 避免上下文重复使用一个变量，使用 final 可以强制重新定义一个变量，方便更好地进行重构。

1.【强制】关于hashCode和equals的处理，遵循如下规则:

1) 只要覆写 equals，就必须覆写 hashCode。
2) 因为 Set 存储的是不重复的对象，依据 hashCode 和 equals 进行判断，所以 Set 存储的对象必须覆 写这两个方法。
3) 如果自定义对象作为 Map 的键，那么必须覆写 hashCode 和 equals。

说明:String 已覆写 hashCode 和 equals 方法，所以我们可以愉快地使用 String 对象作为 key 来使用

2.【强制】ArrayList 的 subList 结果不可强转成 ArrayList，否则会抛出 ClassCastException 异常

6.【强制】使用集合转数组的方法，必须使用集合的toArray(T[]array)，传入的是类型完全一
致、长度为 0 的空数组。

List<String> list = new ArrayList<>(2);
list.add("guan");
list.add("bao");
String[] array = list.toArray(new String[0]);

7.【强制】在使用 Collection 接口任何实现类的 addAll()方法时，都要对输入的集合参数进行 NPE 判断。

8.【强制】使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方 法，它的 add/remove/clear 方法会抛出 UnsupportedOperationException 异常。

9.【强制】泛型通配符<?extendsT>来接收返回的数据，此写法的泛型集合不能使用 add()，而<? super T>不能使用 get()，作为接口调用赋值时易出错。

说明:扩展说一下 PECS(Producer Extends Consumer Super)原则:第一、频繁往外读取内容的，适合 用<? extends T>。第二、经常往里插入的，适合用<? super T>

12.【强制】在 JDK7 版本及以上，Comparator 实现类要满足如下三个条件，不然 Arrays.sort， Collections.sort 会抛 IllegalArgumentException 异常。

说明:三个条件如下

1) x，y 的比较结果和 y，x 的比较结果相反。
2) x>y，y>z，则 x>z。
3) x=y，则 x，z 比较结果和 y，z 比较结果相同。

17.【参考】合理利用好集合的稳定性(order)和有序性(sort)，避免集合的无序性(unsort)和不稳定性(unorder)带来的负面影响。

说明:有序性是指遍历的结果是按某种比较规则依次排列的。稳定性指集合每次遍历的元素次序是一定的。如:ArrayList 是 order/unsort;HashMap 是 unorder/unsort;TreeSet 是 order/sort

1.【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。

说明:资源驱动类、工具类、单例工厂类都需要注意。

4.【强制】线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。

5.【强制】SimpleDateFormat 是线程不安全的类，一般不要定义为static变量，如果定义为
static，必须加锁，或者使用 DateUtils 工具类。

正例:注意线程安全，使用 DateUtils。亦推荐如下处理:

private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() {
    @Override
    protected DateFormat initialValue() {
    return new SimpleDateFormat("yyyy-MM-dd");
    }
};

6.【强制】必须回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用， 如果不清理自定义的 ThreadLocal 变量，可能会影响后续业务逻辑和造成内存泄露等问题。 尽量在代理中使用 try-finally 块进行回收。

objectThreadLocal.set(userInfo);
try {
    // ...
} finally {
    objectThreadLocal.remove();
}

7.【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁; 能锁区块，就不要锁整个方法体;能用对象锁，就不要用类锁。

说明:尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用 RPC 方法。

8.【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。

说明:线程一需要对表 A、B、C 依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是 A、B、C，否则可能出现死锁。

9.【强制】在使用阻塞等待获取锁的方式中，必须在try代码块之外，并且在加锁方法与try代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在 finally 中无法解锁。

10.【强制】在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是
否持有锁。锁的释放规则与锁的阻塞等待方式相同。

Lock lock = new XxxLock();
// ...
boolean isLocked = lock.tryLock();
if (isLocked) {
    try {
        doSomething();
        doOthers();
    } finally {
        lock.unlock();
    }
}

12.【强制】多线程并行处理定时任务时，Timer 运行多个 TimeTask 时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行，如果在处理定时任务时使用 ScheduledExecutorService 则没有这个问题。

13.【推荐】资金相关的金融敏感信息，使用悲观锁策略。

14.【推荐】使用 CountDownLatch 进行异步转同步操作，每个线程退出前必须调用 countDown 方法，线程执行代码注意 catch 异常，确保 countDown 方法被执行到，避免主线程无法执行至 await 方法，直到超时才返回结果。

说明:注意，子线程抛出异常堆栈，不能在主线程 try-catch 到。

15.【推荐】避免 Random 实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一 seed 导致的性能下降。

正例:在 JDK7 之后，可以直接使用 API ThreadLocalRandom，而在 JDK7 之前，需要编码保证每个线 程持有一个实例。

18.【参考】HashMap 在容量不够进行 resize 时由于高并发可能出现死链，导致 CPU 飙升，在开发过程中可以使用其它数据结构或加锁来规避此风险。

19.【参考】ThreadLocal 对象使用 static 修饰，ThreadLocal 无法解决共享对象的更新问题。

说明:这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义 的)都可以操控这个变量。

注意：每个线程往threadlocal中读取数据都是线程隔离，互相之间不影响，所以threadlocal无法解决共享对象的更新问题。由于不需要共享信息，自然不存在竞争问题了，从而保证了某些情况下线程安全问题，以及避免了某些情况必须要考虑线程安全必须同步带来的性能损失

2.【强制】当switch括号内的变量类型为String并且此变量为外部参数时，必须先进行null 判断。

4.【强制】在高并发场景中，避免使用“等于”判断作为中断或退出的条件

说明:如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件
来代替。

反例:判断剩余奖品数量等于 0 时，终止发放奖品，但因为并发处理错误导致奖品数量瞬间变成了负数，
这样的话，活动无法终止。

5.【推荐】表达异常的分支时，少用if-else方式，这种方式可以改写成:

if (condition) {
    ...
    return obj;
}

11.【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫 描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。

1) 待办事宜(TODO):(标记人，标记时间，[预计处理时间]) 表示需要实现，但目前还未实现的功能。这实际上是一个 Javadoc 的标签，目前的 Javadoc 还没有实现，但已经被广泛使用。只能应用于类，接口和方法(因为它是一个 Javadoc 标签)。
2) 错误，不能工作(FIXME):(标记人，标记时间，[预计处理时间])
在注释中用 FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。

5.【强制】获取当前毫秒数 System.currentTimeMillis(); 而不是 new Date().getTime();

说明:如果想获取更加精确的纳秒级时间值，使用 System.nanoTime()的方式。在 JDK8 中，针对统计时 间等场景，推荐使用 Instant 类。

12.【推荐】定义时区分 unchecked / checked 异常，避免直接抛出 new RuntimeException()， 更不允许抛出 Exception 或者 Throwable，应使用有业务含义的自定义异常。推荐业界已定 义过的自定义异常，如:DAOException / ServiceException 等。

13.【参考】对于公司外的 http/api 开放接口必须使用“错误码”;而应用内部推荐异常抛出; 跨应用间 RPC 调用优先考虑使用 Result 方式，封装 isSuccess()方法、“错误码”、“错误 简短信息”。

说明:关于 RPC 方法返回方式使用 Result 方式的理由:

1)使用抛异常返回方式，调用方如果没有捕获到就会产生运行时错误。
2)如果不加栈信息，只是 new 自定义异常，加入自己的理解的 error message，对于调用端解决问题 的帮助不会太多。如果加了栈信息，在频繁调用出错的情况下，数据序列化和传输的性能损耗也是问题。

4.【强制】在日志输出时，字符串变量之间的拼接使用占位符的方式。

说明:因为 String 字符串的拼接会使用 StringBuilder 的 append()方式，有一定的性能损耗。使用占位符 仅是替换动作，可以有效提升性能。

正例:logger.debug("Processing trade with id: {} and symbol: {}", id, symbol);

5.【强制】对于trace/debug/info级别的日志输出，必须进行日志级别的开关判断。 说明:虽然在 debug(参数)的方法体内第一行代码 isDisabled(Level.DEBUG_INT)为真时(Slf4j 的常见实 现 Log4j 和 Logback)，就直接 return，但是参数可能会进行字符串拼接运算。此外，如果 debug(getName())这种参数内有 getName()方法调用，无谓浪费方法调用的开销。

// 如果判断为真，那么可以输出 trace 和 debug 级别的日志
if (logger.isDebugEnabled()) {
    logger.debug("Current ID is: {} and name is: {}", id, getName());
}

1.【强制】好的单元测试必须遵守 AIR 原则。

说明:单元测试在线上运行时，感觉像空气(AIR)一样并不存在，但在测试质量的保障上，却是非常关键的。好的单元测试宏观上来说，具有自动化、独立性、可重复执行的特点。

A:Automatic(自动化) 
I:Independent(独立性)
R:Repeatable(可重复)

9.【推荐】编写单元测试代码遵守BCDE原则，以保证被测试模块的交付质量。

B:Border，边界值测试，包括循环边界、特殊取值、特殊时间点、数据顺序等。
C:Correct，正确的输入，并得到预期的结果。
D:Design，与设计文档相结合，来编写单元测试。
E:Error，强制错误信息输入(如:非法数据、异常流程、业务允许外等)，并得到预期的结果

3.【强制】用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定，防止SQL注入，禁止字符串拼接 SQL 访问数据库

4.【强制】用户请求传入的任何参数必须做有效性验证。 说明:忽略参数校验可能导致:

page size 过大导致内存溢出
恶意 order by 导致数据库慢查询
任意重定向
SQL 注入
反序列化注入
正则输入源串拒绝服务 ReDoS

说明:Java 代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题，但是如果攻 击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果

7.【强制】在使用平台资源，譬如短信、邮件、电话、下单、支付，必须实现正确的防重放的 机制，如数量限制、疲劳度控制、验证码校验，避免被滥刷而导致资损。

说明:如注册时发送验证码到手机，如果没有限制次数和频率，那么可以利用此功能骚扰到其它用户，并 造成短信平台资源浪费。

8.【推荐】发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词 过滤等风控策略。

MySQL数据库

1.【强制】表达是与否概念的字段，必须使用is_xxx 的方式命名，数据类型是 unsigned tinyint（1表示是，0表示否）

2.【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。

说明：MySQL在Windows下不区分大小写，但是在Linux下默认是区分大小写的。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝

3.【强制】表名不使用复数名词。

6.【强制】小数类型为decimal，禁止使用float和double。

7.【强制】如果存储的字符串长度几乎相等，使用char定长字符串类型。

8.【强制】varchar是可变长字符串，不预先分配存储空间，长度不要超过5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

13.【推荐】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循:

1) 不是频繁修改的字段。
2) 不是 varchar 超长字段，更不能是 text 字段。
3) 不是唯一索引的字段。 正例:商品类目名称使用频率高，字段长度短，名称基本一不变，可在相关联的表中冗余存储类目名 称，避免关联查询。

14.【推荐】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

说明:如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

1.【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。

说明:不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的;另外， 即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生

2.【强制】超过三个表禁止join。需要join的字段，数据类型必须绝对一致;多表关联查询时，保证被关联的字段需要有索引。

说明:即使双表 join 也要注意表索引、SQL 性能。

3.【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

4.【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

说明:因为左模糊或者全模糊不走索引

5.【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合 索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

正例:where a=? and b=? order by c; 索引:a_b_c

反例:索引如果存在范围查询，那么索引有序性无法利用，如:WHERE a>10 ORDER BY b; 索引 a_b 无法排序。

7.【推荐】利用延迟关联或者子查询优化超多分页场景。

说明:MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。

正例:先快速定位需要获取的 id 段，然后再关联:

SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

原因：mysql查询时，offset过大影响性能的原因是多次通过主键索引访问数据块的I/O操作。（注意，只有InnoDB有这个问题，而MYISAM索引结构与InnoDB不同，二级索引都是直接指向数据块的，因此没有此问题）

参考文献：mysql查询时offset过大影响性能的原因和优化详解

8.【推荐】SQL性能优化目标，EXPALIN的结果，type显示的是访问类型，是较为重要的一个指标，结果值从好到坏依次是：system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 一般来说，得保证查询至少达到range级别，最好能达到ref

9.【推荐】建组合索引的时候，区分度最高的在最左边。

正例:如果 where a=? and b=? ，如果 a 列的几乎接近于唯一值，那么只需要单建 idx_a 索引即可。

11.【参考】创建索引时避免有如下极端误解:

1) 宁滥勿缺。认为一个查询就需要建一个索引。
2) 宁缺勿滥。认为索引会消耗空间、严重拖慢记录的更新以及行的新增速度。
3) 抵制惟一索引。认为业务的惟一性一律需要在应用层通过“先查后插”方式解决。

SQL语句

1.【强制】不要使用count(列名)或count(常量)来替代count()，count()是SQL92定义的 标准统计行数的语法，跟数据库无关，跟 NULL 和非 NULL 无关。

说明:count(*)会统计值为 NULL 的行，而 count(列名)不会统计此列为 NULL 值的行。

2.【强制】count(distinct col) 计算该列除 NULL 之外的不重复行数，注意 count(distinct col1, col2) 如果其中一列全为 NULL，那么即使另一列有不同的值，也返回为 0。

3.【强制】当某一列的值全是NULL时，count(col)的返回结果为0，但sum(col)的返回结果 为 NULL，因此使用 sum()时需注意 NPE 问题。

正例:使用如下方式来避免 sum 的 NPE 问题:SELECT IFNULL(SUM(column), 0) FROM table;

4.【强制】使用ISNULL()来判断是否为NULL值。

说明:NULL 与任何值的直接比较都为 NULL。

1) NULL<>NULL 的返回结果是 NULL，而不是 false。
2) NULL=NULL 的返回结果是 NULL，而不是 true。
3) NULL<>1 的返回结果是 NULL，而不是 true。

5.【强制】代码中写分页查询逻辑时，若count为0应直接返回，避免执行后面的分页语句。

6.【强制】不得使用外键与级联，一切外键概念必须在应用层解决。

说明:以学生和成绩的关系为例，学生表中的 student_id 是主键，那么成绩表中的 student_id 则为外 键。如果更新学生表中的 student_id，同时触发成绩表中的 student_id 更新，即为级联更新。外键与级 联更新适用于单机低并发，不适合分布式、高并发集群;级联更新是强阻塞，存在数据库更新风暴的风 险;外键影响数据库的插入速度。

7.【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。

8.【强制】数据订正(特别是删除、修改记录操作)时，要先select，避免出现误删除，确认无
误才能执行更新语句。

9.【推荐】in操作能避免则避免，若实在避免不了，需要仔细评估in后边的集合元素数量，控 制在 1000 个之内。

11.【参考】TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少，但 TRUNCATE 无事务且不触发 trigger，有可能造成事故，故不建议在开发代码中使用此语句。

说明:TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE 语句相同。

ORM映射

1.【强制】在表查询中，一律不要使用 * 作为查询的字段列表，需要哪些字段必须明确写明。

1)增加查询分析器解析成本。
2)增减字段容易与 resultMap 配置不一致。
3)无用字段增加网络 消耗，尤其是 text 类型的字段。

3.【强制】不要用resultClass当返回参数，即使所有类属性名与数据库字段一一对应，也需要定义;反过来，每一个表也必然有一个 POJO 类与之对应。

说明:配置映射关系，使字段与 DO 类解耦，方便维护。

4.【强制】sql.xml 配置参数使用:#{}，#param# 不要使用${} 此种方式容易出现 SQL 注入。

7.【强制】更新数据表记录时，必须同时更新记录对应的gmt_modified字段值为当前时间。

1.【推荐】图中默认上层依赖于下层，箭头关系表示可直接依赖，如:开放接口层可以依赖于 Web 层，也可以直接依赖于 Service 层，依此类推:

• 开放接口层:可直接封装 Service 方法暴露成 RPC 接口;通过 Web 封装成 http 接口;进行网关安 全控制、流量控制等。
• 终端显示层:各个端的模板渲染并执行显示的层。当前主要是 velocity 渲染，JS 渲染，JSP 渲染，移 动端展示等。
• Web 层:主要是对访问控制进行转发，各类基本参数校验，或者不复用的业务简单处理等。
• Service 层:相对具体的业务逻辑服务层。
• Manager 层:通用业务处理层，它有如下特征:
  1) 对第三方平台封装的层，预处理返回结果及转化异常信息。
  2) 对 Service 层通用能力的下沉，如缓存方案、中间件通用处理。
  3) 与 DAO 层交互，对多个 DAO 的组合复用。
• DAO 层:数据访问层，与底层 MySQL、Oracle、Hbase 等进行数据交互。
• 外部接口或第三方平台:包括其它部门 RPC 开放接口，基础平台，其它公司的 HTTP 接口。

2.【参考】(分层异常处理规约)在DAO层，产生的异常类型有很多，无法用细粒度的异常进 行 catch，使用 catch(Exception e)方式，并 throw new DAOException(e)，不需要打印日志，因 为日志在 Manager/Service 层一定需要捕获并打印到日志文件中去，如果同台服务器再打日 志，浪费性能和存储。在 Service 层出现异常时，必须记录出错日志到磁盘，尽可能带上参数 信息，相当于保护案发现场。如果 Manager 层与 Service 同机部署，日志方式与 DAO 层处理 一致，如果是单独部署，则采用与 Service 一致的处理方式。Web 层绝不应该继续往上抛异 常，因为已经处于顶层，如果意识到这个异常将导致页面无法正常渲染，那么就应该直接跳转到友好错误页面，加上用户容易理解的错误提示信息。开放接口层要将异常处理成错误码
和错误信息方式返回。

4.【推荐】在线上生产环境，JVM的Xms和Xmx设置一样大小的内存容量，避免在GC 后调整 堆大小带来的压力。

1.【强制】存储方案和底层数据结构的设计获得评审一致通过，并沉淀成为文档。

说明:有缺陷的底层数据结构容易导致系统风险上升，可扩展性下降，重构成本也会因历史数据迁移和系
统平滑过渡而陡然增加，所以，存储方案和数据结构需要认真地进行设计和评审，生产环境提交执行后，
需要进行 double check。

正例:评审内容包括存储介质选型、表结构设计能否满足技术方案、存取性能和存储空间能否满足业务发
展、表或字段之间的辩证关系、字段名称、字段类型、索引等;数据结构变更(如在原有表中新增字段)
也需要进行评审通过后上线。

7.【推荐】需求分析与系统设计在考虑主干功能的同时，需要充分评估异常流程与业务边界。

反例:用户在淘宝付款过程中，银行扣款成功，发送给用户扣款成功短信，但是支付宝入款时由于断网演练产生异常，淘宝订单页面依然显示未付款，导致用户投诉。

8.【推荐】类在设计与实现时要符合单一原则。 说明:单一原则最易理解却是最难实现的一条规则，随着系统演进，很多时候，忘记了类设计的初衷。

9.【推荐】谨慎使用继承的方式来进行扩展，优先使用聚合/组合的方式来实现。

说明:不得已使用继承的话，必须符合里氏代换原则，此原则说父类能够出现的地方子类一定能够出现， 比如，“把钱交出来”，钱的子类美元、欧元、人民币等都可以出现。

10.【推荐】系统设计时，根据依赖倒置原则，尽量依赖抽象类与接口，有利于扩展与维护。

说明:低层次模块依赖于高层次模块的抽象，方便系统间的解耦。

16.【参考】系统架构设计的目的:

1）确定系统边界。确定系统在技术层面上的做与不做。
2）确定系统内模块之间的关系。确定模块之间的依赖关系及模块的宏观输入与输出。
3）确定指导后续设计与演化的原则。使后续的子系统或模块设计在规定的框架内继续演化。
4）确定非功能性需求。非功能性需求是指安全性、可用性、可扩展性等。

• 【阿里巴巴Java开发手册1.5】书籍