【阿里巴巴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 来判断

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

反例:

1
2
3
4
5
6
7
8
9
10
11
12
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) 指定一个误差范围,两个浮点数的差值在此范围之内,则认为是相等的。

1
2
3
4
5
6
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 来定义值,再进行浮点数的运算操作。

1
2
3
4
5
6
7
8
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 的风险

1
2
3
4
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 的空数组。

正例:

1
2
3
4
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.sortCollections.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。亦推荐如下处理:

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

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

正例:

1
2
3
4
5
6
objectThreadLocal.set(userInfo);
try {
// ...
} finally {
objectThreadLocal.remove();
}

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

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

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

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

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

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

正例:

1
2
3
4
5
6
7
8
9
10
11
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方式,这种方式可以改写成:

1
2
3
4
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()方法调用,无谓浪费方法调用的开销。

正例:

1
2
3
4
// 如果判断为真,那么可以输出 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 段,然后再关联:

1
SELECT a.* FROM1 a, (select id from1 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 层,依此类推:

image

  • 开放接口层:可直接封装 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】书籍