(六)并发处理
1.【强制】获取单例对象需要保证线程安全，其中的方法也要保证线程安全。
说明：资源驱动类、工具类、单例工厂类都需要注意。
2.【强制】创建线程或线程池时请指定有意义的线程名称，方便出错时回溯。
正例：自定义线程工厂，并且根据外部特征进行分组，比如机房信息。
publicclass UserThreadFactoryimplementsThreadFactory{
privatefinal StringnamePrefix;
privatefinal AtomicIntegernextId =newAtomicInteger(1);
//定义线程组名称，在jstack问题排查时，非常有帮助
UserThreadFactory(StringwhatFeaturOfGroup){
namePrefix="FromUserThreadFactory"s " +whatFeaturOfGroup+"-Worker-";
}
@Override
publicThreadnewThread(Runnabletask){
Stringname =namePrefix+nextId.getAndIncrement();
Threadthread =newThread(null,task,name,0,false);Java开发手册
System.out.println(thread.getName());
returnthread;
}
}
3.【强制】线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。
说明：线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问
题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题。
4.【强制】线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这
样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。
说明：Executors返回的线程池对象的弊端如下：
1）FixedThreadPool和SingleThreadPool：
允许的请求队列长度为Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM。
2）CachedThreadPool：
允许的创建线程数量为Integer.MAX_VALUE，可能会创建大量的线程，从而导致OOM。
5.【强制】SimpleDateFormat是线程不安全的类，一般不要定义为static变量，如果定义为
static，必须加锁，或者使用DateUtils工具类。
正例：注意线程安全，使用DateUtils。亦推荐如下处理：
privatestatic final ThreadLocal<DateFormat> df = newThreadLocal<DateFormat>() {
@Override
protectedDateFormat initialValue() {
returnnew SimpleDateFormat("yyyy-MM-dd");
}
};
说明：如果是JDK8的应用，可以使用Instant代替Date，LocalDateTime代替Calendar，
DateTimeFormatter代替SimpleDateFormat，官方给出的解释：simplebeautiful strong immutable
thread-safe。
6.【强制】必须回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用，
如果不清理自定义的ThreadLocal变量，可能会影响后续业务逻辑和造成内存泄露等问题。
尽量在代理中使用try-finally块进行回收。
正例：
objectThreadLocal.set(userInfo);
try{
//...
}finally {
objectThreadLocal.remove();
}
7.【强制】高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；
能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁。
说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。
15/44Java开发手册
8.【强制】对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会
造成死锁。
说明：线程一需要对表A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是
A、B、C，否则可能出现死锁。
9.【强制】在使用阻塞等待获取锁的方式中，必须在try代码块之外，并且在加锁方法与try代
码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在finally中无法解锁。
说明一：如果在lock方法与try代码块之间的方法调用抛出异常，那么无法解锁，造成其它线程无法成功
获取锁。
说明二：如果lock方法在try代码块之内，可能由于其它方法抛出异常，导致在finally代码块中，
unlock对未加锁的对象解锁，它会调用AQS的tryRelease方法（取决于具体实现类），抛出
IllegalMonitorStateException异常。
说明三：在Lock对象的lock方法实现中可能抛出unchecked异常，产生的后果与说明二相同。
正例：
Locklock = new XxxLock();
//...
lock.lock();
try{
doSomething();
doOthers();
}finally {
lock.unlock();
}
反例：
Locklock = new XxxLock();
//...
try{
//如果此处抛出异常，则直接执行finally代码块
doSomething();
//无论加锁是否成功，finally代码块都会执行
lock.lock();
doOthers();
}finally {
lock.unlock();
}
10.【强制】在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是
否持有锁。锁的释放规则与锁的阻塞等待方式相同。
说明：Lock对象的unlock方法在执行时，它会调用AQS的tryRelease方法（取决于具体实现类），如果
当前线程不持有锁，则抛出IllegalMonitorStateException异常。
正例：
Locklock = new XxxLock();
//...
booleanisLocked = lock.tryLock();
if(isLocked) {
try{
doSomething();
16/44Java开发手册
doOthers();
}finally {
lock.unlock();
}
}
11.【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存
加锁，要么在数据库层使用乐观锁，使用version作为更新依据。
说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于
3次。
12.【强制】多线程并行处理定时任务时，Timer运行多个TimeTask时，只要其中之一没有捕获
抛出的异常，其它任务便会自动终止运行，如果在处理定时任务时使用
ScheduledExecutorService则没有这个问题。
13.【推荐】资金相关的金融敏感信息，使用悲观锁策略。
说明：乐观锁在获得锁的同时已经完成了更新操作，校验逻辑容易出现漏洞，另外，乐观锁对冲突的解决
策略有较复杂的要求，处理不当容易造成系统压力或数据异常，所以资金相关的金融敏感信息不建议使用
乐观锁更新。
14.【推荐】使用CountDownLatch进行异步转同步操作，每个线程退出前必须调用countDown
方法，线程执行代码注意catch异常，确保countDown方法被执行到，避免主线程无法执行
至await方法，直到超时才返回结果。
说明：注意，子线程抛出异常堆栈，不能在主线程try-catch到。
15.【推荐】避免Random实例被多线程使用，虽然共享该实例是线程安全的，但会因竞争同一
seed导致的性能下降。
说明：Random实例包括java.util.Random的实例或者Math.random()的方式。
正例：在JDK7之后，可以直接使用APIThreadLocalRandom，而在JDK7之前，需要编码保证每个线
程持有一个实例。
16.【推荐】在并发场景下，通过双重检查锁（double-checkedlocking）实现延迟初始化的优化
问题隐患(可参考The"Double-CheckedLocking is Broken"Declaration)，推荐解决方案中较为
简单一种（适用于JDK5及以上版本），将目标属性声明为volatile型。
反例：
publicclass LazyInitDemo {
privateHelper helper = null;
publicHelper getHelper() {
if(helper == null) synchronized(this) {
if(helper == null)
helper= new Helper();
}
returnhelper;
}
//other methods and fields...
}
17/44Java开发手册
17.【参考】volatile解决多线程内存不可见问题。对于一写多读，是可以解决变量同步问题，但
是如果多写，同样无法解决线程安全问题。
说明：如果是count++操作，使用如下类实现：AtomicIntegercount = new AtomicInteger();
count.addAndGet(1);如果是JDK8，推荐使用LongAdder对象，比AtomicLong性能更好（减少乐观
锁的重试次数）。
18.【参考】HashMap在容量不够进行resize时由于高并发可能出现死链，导致CPU飙升，在
开发过程中可以使用其它数据结构或加锁来规避此风险。
19.【参考】ThreadLocal对象使用static修饰，ThreadLocal无法解决共享对象的更新问题。
说明：这个变量是针对一个线程内所有操作共享的，所以设置为静态变量，所有此类实例共享此静态变
量，也就是说在类第一次被使用时装载，只分配一块存储空间，所有此类的对象(只要是这个线程内定义
的)都可以操控这个变量。
(七)控制语句
1.【强制】在一个switch块内，每个case要么通过continue/break/return等来终止，要么
注释说明程序将继续执行到哪一个case为止；在一个switch块内，都必须包含一个
default语句并且放在最后，即使它什么代码也没有。
说明：注意break是退出switch语句块，而return是退出方法体。
2.【强制】当switch括号内的变量类型为String并且此变量为外部参数时，必须先进行null
判断。
反例：猜猜下面的代码输出是什么？
publicclass SwitchString {
publicstatic void main(String[] args) {
method(null);
}
publicstatic void method(String param) {
switch(param) {
//肯定不是进入这里
case"sth":
System.out.println("it"ssth");
break;
//也不是进入这里
case"null":
System.out.println("it"snull");
break;
//也不是进入这里
default:
System.out.println("default");
}
}
}
18/44Java开发手册
3.【强制】在if/else/for/while/do语句中必须使用大括号。
说明：即使只有一行代码，避免采用单行的编码方式：if(condition) statements;
4.【强制】在高并发场景中，避免使用”等于”判断作为中断或退出的条件。
说明：如果并发控制没有处理好，容易产生等值判断被“击穿”的情况，使用大于或小于的区间判断条件
来代替。
反例：判断剩余奖品数量等于0时，终止发放奖品，但因为并发处理错误导致奖品数量瞬间变成了负数，
这样的话，活动无法终止。
5.【推荐】表达异常的分支时，少用if-else方式，这种方式可以改写成：
if(condition) {
...
returnobj;
}
//接着写else的业务逻辑代码;
说明：如果非使用if()...elseif()...else...方式表达逻辑，避免后续代码维护困难，【强制】请勿超过3层。
正例：超过3层的if-else的逻辑判断代码可以使用卫语句、策略模式、状态模式等来实现，其中卫语句
即代码逻辑先考虑失败、异常、中断、退出等直接返回的情况，以方法多个出口的方式，解决代码中判断
分支嵌套的问题，这是逆向思维的体现。
示例如下：
publicvoid findBoyfriend(Man man) {
if(man.isUgly()){
System.out.println("本姑娘是外貌协会的资深会员");
return;
}
if(man.isPool()){
System.out.println("贫贱夫妻百事哀");
return;
}
if(man.isBadTemper()){
System.out.println("银河有多远，你就给我滚多远");
return;
}
System.out.println("可以先交往一段时间看看");
}
6.【推荐】除常用方法（如getXxx/isXxx）等外，不要在条件判断中执行其它复杂的语句，将复
杂逻辑判断的结果赋值给一个有意义的布尔变量名，以提高可读性。
说明：很多if语句内的逻辑表达式相当复杂，与、或、取反混合运算，甚至各种方法纵深调用，理解成
本非常高。如果赋值一个非常好理解的布尔变量名字，则是件令人爽心悦目的事情。
正例：
//伪代码如下
finalboolean existed = (file.open(fileName, "w") != null) &&(...) || (...);
19/44Java开发手册
if(existed) {
...
}
反例：
publicfinal void acquire(long arg) {
if(!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE),arg)) {
selfInterrupt();
}
}
7.【推荐】不要在其它表达式（尤其是条件表达式）中，插入赋值语句。
说明：赋值点类似于人体的穴位，对于代码的理解至关重要，所以赋值语句需要清晰地单独成为一行。
反例：
publicLock getLock(boolean fair) {
//算术表达式中出现赋值操作，容易忽略count值已经被改变
threshold= (count = Integer.MAX_VALUE) - 1;
//条件表达式中出现赋值操作，容易误认为是sync==fair
return(sync = fair) ? new FairSync() : new NonfairSync();
}
8.【推荐】循环体中的语句要考量性能，以下操作尽量移至循环体外处理，如定义对象、变
量、获取数据库连接，进行不必要的try-catch操作（这个try-catch是否可以移至循环体
外）。
9.【推荐】避免采用取反逻辑运算符。
说明：取反逻辑不利于快速理解，并且取反逻辑写法必然存在对应的正向逻辑写法。
正例：使用if(x < 628) 来表达x小于628。
反例：使用if(!(x >= 628)) 来表达x小于628。
10.【推荐】接口入参保护，这种场景常见的是用作批量操作的接口。
11.【参考】下列情形，需要进行参数校验：
1）调用频次低的方法。
2）执行时间开销很大的方法。此情形中，参数校验时间几乎可以忽略不计，但如果因为参数错误导致
中间执行回退，或者错误，那得不偿失。
3）需要极高稳定性和可用性的方法。
4）对外提供的开放接口，不管是 RPC/API/HTTP接口。
5）敏感权限入口。
12.【参考】下列情形，不需要进行参数校验：
1）极有可能被循环调用的方法。但在方法说明里必须注明外部参数检查要求。
2）底层调用频度比较高的方法。毕竟是像纯净水过滤的最后一道，参数错误不太可能到底层才会暴露
问题。一般DAO层与Service层都在同一个应用中，部署在同一台服务器中，所以DAO的参数校验，可
以省略。
20/44Java开发手册
3）被声明成 private只会被自己代码所调用的方法，如果能够确定调用方法的代码传入参数已经做过检
查或者肯定不会有问题，此时可以不校验参数。
(八)注释规约
1.【强制】类、类属性、类方法的注释必须使用Javadoc规范，使用/**内容*/格式，不得使用
//xxx 方式。
说明：在IDE编辑窗口中，Javadoc方式会提示相关注释，生成Javadoc可以正确输出相应注释；在IDE
中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
2.【强制】所有的抽象方法（包括接口中的方法）必须要用Javadoc注释、除了返回值、参数、
异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明：对子类的实现要求，或者调用注意事项，请一并说明。
3.【强制】所有的类都必须添加创建者和创建日期。
4.【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释
使用/**/注释，注意与代码对齐。
5.【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
6.【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保
持英文原文即可。
反例：“TCP连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
7.【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻
辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了
导航的意义。
8.【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信
息，难以知晓注释动机。后者建议直接删掉（代码仓库已然保存了历史代码）。
9.【参考】对于注释的要求：第一、能够准确反映设计思想和代码逻辑；第二、能够描述业务
含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者
形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继
任者看的，使其能够快速接替自己的工作。
10.【参考】好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的
一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。
21/44Java开发手册
反例：
//put elephant into fridge
put(elephant,fridge);
方法名put，加上两个有意义的变量名elephant和fridge，已经说明了这是在干什么，语义清晰的代
码不需要额外的注释。
11.【参考】特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫
描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。
1）待办事宜（TODO）:（标记人，标记时间，[预计处理时间]）
表示需要实现，但目前还未实现的功能。这实际上是一个Javadoc的标签，目前的Javadoc还没
有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个Javadoc标签）。
2）错误，不能工作（FIXME）:（标记人，标记时间，[预计处理时间]）
在注释中用FIXME标记某代码是错误的，而且不能工作，需要及时纠正的情况。
(九)其它
1.【强制】在使用正则表达式时，利用好其预编译功能，可以有效加快正则匹配速度。
说明：不要在方法体内定义：Patternpattern = pile(“规则”);
2.【强制】velocity调用POJO类的属性时，直接使用属性名取值即可，模板引擎会自动按规范
调用POJO的getXxx()，如果是boolean基本数据类型变量（boolean命名不需要加is前
缀），会自动调用isXxx()方法。
说明：注意如果是Boolean包装类对象，优先调用getXxx()的方法。
3.【强制】后台输送给页面的变量必须加$!{var}——中间的感叹号。
说明：如果var等于null或者不存在，那么${var}会直接显示在页面上。
4.【强制】注意Math.random()这个方法返回是double类型，注意取值的范围0≤x<1（能够
取到零值，注意除零异常），如果想获取整数类型的随机数，不要将x放大10的若干倍然后
取整，直接使用Random对象的nextInt或者nextLong方法。
5.【强制】获取当前毫秒数System.currentTimeMillis();而不是newDate().getTime();
说明：如果想获取更加精确的纳秒级时间值，使用System.nanoTime()的方式。在JDK8中，针对统计时
间等场景，推荐使用Instant类。
6.【强制】日期格式化时，传入pattern中表示年份统一使用小写的y。
说明：日期格式化时，yyyy表示当天所在的年，而大写的YYYY代表是weekin which year
（JDK7之后引入的概念），意思是当天所在的周属于的年份，一周从周日开始，周六结束，
只要本周跨年，返回的YYYY就是下一年。另外需要注意：
⚫ 表示月份是大写的M
22/44Java开发手册
⚫ 表示分钟则是小写的m
⚫ 24小时制的是大写的H
⚫ 12小时制的则是小写的h
正例：表示日期和时间的格式如下所示：
newSimpleDateFormat("yyyy-MM-dd HH:mm:ss");
7.【推荐】不要在视图模板中加入任何复杂的逻辑。
说明：根据MVC理论，视图的职责是展示，不要抢模型和控制器的活。
8.【推荐】任何数据结构的构造或初始化，都应指定大小，避免数据结构无限增长吃光内存。
9.【推荐】及时清理不再使用的代码段或配置信息。
说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。
正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)
来说明注释掉代码的理由。
