java 并发处理规范

(九) 并发处理
Rule 1. 【强制】创建线程或线程池时请指定有意义的线程名称，方便出错时回溯

1）创建单条线程时直接指定线程名称

1 2	Thread t = new Thread(); t.setName("cleanup-thread");

2）线程池则使用 guava 或自行封装的 ThreadFactory，指定命名规则。

//guava 或自行封装的ThreadFactory
ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat(threadNamePrefix + "-%d").build();

ThreadPoolExecutor executor = new ThreadPoolExecutor(..., threadFactory, ...);

Rule 2. 【推荐】尽量使用线程池来创建线程

除特殊情况，尽量不要自行创建线程，更好的保护线程资源。

1
2
3

//WRONG
Thread thread = new Thread(...);
thread.start();

同理，定时器也不要使用 Timer，而应该使用 ScheduledExecutorService。

因为 Timer 只有单线程，不能并发的执行多个在其中定义的任务，而且如果其中一个任务抛出异常，整个 Timer 也会挂掉，而 ScheduledExecutorService 只有那个没捕获到异常的任务不再定时执行，其他任务不受影响。

Rule 3. 【强制】线程池不允许使用 Executors 去创建，避资源耗尽风险

Executors 返回的线程池对象的弊端：

1）FixedThreadPool 和 SingleThreadPool:

允许的请求队列长度为 Integer.MAX_VALUE，可能会堆积大量的请求，从而导致 OOM。

2）CachedThreadPool 和 ScheduledThreadPool:

允许的创建线程数量为 Integer.MAX_VALUE，可能会创建大量的线程，从而导致 OOM。

应通过 new ThreadPoolExecutor(xxx,xxx,xxx,xxx)这样的方式，更加明确线程池的运行规则，合理设置 Queue 及线程池的 core size 和 max size，建议使用 vjkit 封装的 ThreadPoolBuilder。

Rule 4. 【强制】正确停止线程

Thread.stop()不推荐使用，强行的退出太不安全，会导致逻辑不完整，操作不原子，已被定义成 Deprecate 方法。

停止单条线程，执行 Thread.interrupt()。

停止线程池：

ExecutorService.shutdown(): 不允许提交新任务，等待当前任务及队列中的任务全部执行完毕后退出；

ExecutorService.shutdownNow(): 通过 Thread.interrupt()试图停止所有正在执行的线程，并不再处理还在队列中等待的任务。

最优雅的退出方式是先执行 shutdown()，再执行 shutdownNow()，vjkit 的 ThreadPoolUtil 进行了封装。

注意，Thread.interrupt()并不保证能中断正在运行的线程，需编写可中断退出的 Runnable，见规则 5。

Rule 5. 【强制】编写可停止的 Runnable

执行 Thread.interrupt()时，如果线程处于 sleep(), wait(), join(), lock.lockInterruptibly()等 blocking 状态，会抛出 InterruptedException，如果线程未处于上述状态，则将线程状态设为 interrupted。

因此，如下的代码无法中断线程:

public void run() {

  while (true) { //WRONG，无判断线程状态。
    sleep();
  }

  public void sleep() {
    try {
      Thread.sleep(1000);
    } catch (InterruptedException e) {
      logger.warn("Interrupted!", e); //WRONG，吃掉了异常，interrupt状态未再传递
    }
  }
}

5.1 正确处理 InterruptException

因为 InterruptException 异常是个必须处理的 Checked Exception，所以 run()所调用的子函数很容易吃掉异常并简单的处理成打印日志，但这等于停止了中断的传递，外层函数将收不到中断请求，继续原有循环或进入下一个堵塞。

正确处理是调用 Thread.currentThread().interrupt(); 将中断往外传递。

//RIGHT
public void myMethod() {
  try {
    ...
  } catch (InterruptedException e) {
    Thread.currentThread().interrupt();
  }
}

Sonar-2142: “InterruptedException” should not be ignored
5.2 主循环及进入阻塞状态前要判断线程状态

//RIGHT
public void run() {
  try {
    while (!Thread.isInterrupted()) {
      // do stuff
    }
  } catch (InterruptedException e) {
    logger.warn("Interrupted!", e);
  }
}

其他如 Thread.sleep()的代码，在正式 sleep 前也会判断线程状态。

Rule 6. 【强制】Runnable 中必须捕获一切异常

如果 Runnable 中没有捕获 RuntimeException 而向外抛出，会发生下列情况：

ScheduledExecutorService 执行定时任务，任务会被中断，该任务将不再定时调度，但线程池里的线程还能用于其他任务。
ExecutorService 执行任务，当前线程会中断，线程池需要创建新的线程来响应后续任务。
如果没有在 ThreadFactory 设置自定义的 UncaughtExceptionHanlder，则异常最终只打印在 System.err，而不会打印在项目的日志中。

因此建议自写的 Runnable 都要保证捕获异常; 如果是第三方的 Runnable，可以将其再包裹一层 vjkit 中的 SafeRunnable。

1	executor.execute(ThreadPoolUtil.safeRunner(runner));

Rule 7. 【强制】全局的非线程安全的对象可考虑使用 ThreadLocal 存放

全局变量包括单例对象，static 成员变量。

著名的非线程安全类包括 SimpleDateFormat，MD5/SHA1 的 Digest。

对这些类，需要每次使用时创建。

但如果创建有一定成本，可以使用 ThreadLocal 存放并重用。

ThreadLocal 变量需要定义成 static，并在每次使用前重置。

private static final ThreadLocal<MessageDigest> SHA1_DIGEST = new ThreadLocal<MessageDigest>() {
  @Override
  protected MessageDigest initialValue() {
    try {
      return MessageDigest.getInstance("SHA");
    } catch (NoSuchAlgorithmException e) {
      throw new RuntimeException("...", e);
    }
  }
};

public void digest(byte[] input) {
  MessageDigest digest = SHA1_DIGEST.get();
  digest.reset();
  return digest.digest(input);
}

Sonar-2885: Non-thread-safe fields should not be static
Facebook-Contrib: Correctness - Field is an instance based ThreadLocal variable
Rule 8. 【推荐】缩短锁

1）能锁区块，就不要锁整个方法体；

//锁整个方法，等价于整个方法体内 synchronized(this)

1	public synchronized boolean foo(){};

//锁区块方法，仅对需要保护的原子操作的连续代码块进行加锁。

public boolean foo() {
    synchronized(this) {
        ...
        ...
    }
    //other stuff
}

2）能用对象锁，就不要用类锁。

//对象锁，只影响使用同一个对象加锁的线程

1
2
3

synchronized(this) {
    ...
}

//类锁，使用类对象作为锁对象，影响所有线程。

1
2
3

synchronized(A.class) {
    ...
}

Rule 10. 【推荐】选择分离锁，分散锁甚至无锁的数据结构

分离锁：
1）读写分离锁 ReentrantReadWriteLock，读读之间不加锁，仅在写读和写写之间加锁；

2） Array Base 的 queue 一般是全局一把锁，而 Linked Base 的 queue 一般是队头队尾两把锁。

分散锁（又称分段锁）：
1）如 JDK7 的 ConcurrentHashMap，分散成 16 把锁；

2）对于经常写，少量读的计数器，推荐使用 JDK8 或 vjkit 封装的 LongAdder 对象性能更好（内部分散成多个 counter，减少乐观锁的使用，取值时再相加所有 counter）

无锁的数据结构：
1）完全无锁无等待的结构，如 JDK8 的 ConcurrentHashMap；

2）基于 CAS 的无锁有等待的数据结构，如 AtomicXXX 系列。

Rule 11. 【推荐】基于 ThreadLocal 来避免锁

比如 Random 实例虽然是线程安全的，但其实它的 seed 的访问是有锁保护的。因此建议使用 JDK7 的 ThreadLocalRandom，通过在每个线程里放一个 seed 来避免了加锁。

Rule 12. 【推荐】规避死锁风险

对多个资源多个对象的加锁顺序要一致。

如果无法确定完全避免死锁，可以使用带超时控制的 tryLock 语句加锁。

Rule 13. 【推荐】volatile 修饰符，AtomicXX 系列的正确使用

多线程共享的对象，在单一线程内的修改并不保证对所有线程可见。使用 volatile 定义变量可以解决（解决了可见性）。

但是如果多条线程并发进行基于当前值的修改，如并发的 counter++，volatile 则无能为力（解决不了原子性）。

此时可使用 Atomic*系列:

1 2	AtomicInteger count = new AtomicInteger(); count.addAndGet(2);

但如果需要原子地同时对多个 AtomicXXX 的 Counter 进行操作，则仍然需要使用 synchronized 将改动代码块加锁。

Rule 14. 【推荐】延时初始化的正确写法

通过双重检查锁（double-checked locking）实现延迟初始化存在隐患，需要将目标属性声明为 volatile 型，为了更高的性能，还要把 volatile 属性赋予给临时变量，写法复杂。

所以如果只是想简单的延迟初始化，可用下面的静态类的做法，利用 JDK 本身的 class 加载机制保证唯一初始化。

private static class LazyObjectHolder {
  static final LazyObject instance = new LazyObject();
}

public void myMethod() {
  LazyObjectHolder.instance.doSomething();
}

Sonar-2168: Double-checked locking should not be used

来源：https://vipshop.github.io/vjtools/#/standard/chapter09

Tags: 多线程异步并发

← java jdk concurrent 并发工具包 ThreadPoolExecutor使用和思考（上）-线程池大小设置与BlockingQueue的三种实现区别 →

赏

使用支付宝打赏

使用微信打赏

若你觉得我的文章对你有帮助，欢迎点击上方按钮对我打赏

扫描二维码，分享此文章

java 并发处理 规范

java 并发处理 规范

java 并发处理规范

java 并发处理规范