创建线程或线程池时请指定有意义的线程名称，方便出错时回溯
// 正例：自定义线程工厂，并且根据外部特征进行分组，比如机房信息 public class UserThreadFactory implements ThreadFactory { private final String namePrefix; private final AtomicInteger nextId = new AtomicInteger(1); // 定义线程组名称，在 jstack 问题排查时，非常有帮助 UserThreadFactory(String whatFeaturOfGroup) { namePrefix = "From UserThreadFactory's " + whatFeaturOfGroup + "-Worker-"; } @Override public Thread newThread(Runnable task) { String name = namePrefix + nextId.getAndIncrement(); Thread thread = new Thread(null, task, name, 0, false); System.out.println(thread.getName()); return thread; } }线程资源必须通过线程池提供，不允许在应用中自行显式创建线程【说明：线程池的好处是减少在创建和销毁线程上所消耗的时间以及系统资源的开销，解决资源不足的问题。如果不使用线程池，有可能造成系统创建大量同类线程而导致消耗完内存或者“过度切换”的问题】
线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险
说明：Executors返回的线程池对象的弊端如下：
1）FixedThreadPool和SingleThreadPool：
允许的请求队列长度为Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM。
2）CachedThreadPool：
允许的创建线程数量为Integer.MAX_VALUE，可能会创建大量的线程，从而导致OOM。
SimpleDateFormat是线程不安全的类，一般不要定义为static变量，如果定义为static，必须加锁。【说明：如果是JDK8的应用，可以使用Instant代替Date，LocalDateTime代替Calendar，DateTimeFormatter代替SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。】
// 正例：注意线程安全。亦推荐如下处理 private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() { @Override protected DateFormat initialValue() { return new SimpleDateFormat("yyyy-MM-dd"); } };必须回收自定义的ThreadLocal变量，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的ThreadLocal变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量使用try-finally块进行回收
// 正例 objectThreadLocal.set(userInfo); try { // ... } finally { objectThreadLocal.remove(); }高并发时，同步调用应该去考量锁的性能损耗。能用无锁数据结构，就不要用锁；能锁区块，就不要锁整个方法体；能用对象锁，就不要用类锁【说明：尽可能使加锁的代码块工作量尽可能的小，避免在锁代码块中调用RPC方法。】
对多个资源、数据库表、对象同时加锁时，需要保持一致的加锁顺序，否则可能会造成死锁。【说明：线程一需要对表A、B、C依次全部加锁后才可以进行更新操作，那么线程二的加锁顺序也必须是A、B、C，否则可能出现死锁。】
在使用阻塞等待获取锁的方式中，必须在try代码块之外，并且在加锁方法与try代码块之间没有任何可能抛出异常的方法调用，避免加锁成功后，在finally中无法解锁
说明一：如果在lock方法与try代码块之间的方法调用抛出异常，那么无法解锁，造成其它线程无法成功获取锁。
说明二：如果lock方法在try代码块之内，可能由于其它方法抛出异常，导致在 finally代码块中，unlock对未加锁的对象解锁，它会调用AQS的tryRelease方法（取决于具体实现类），抛出IllegalMonitorStateException异常。
说明三：在Lock对象的lock方法实现中可能抛出unchecked异常，产生的后果与说明二相同
// 正例 Lock lock = new XxxLock(); // ... lock.lock(); try { doSomething(); doOthers(); } finally { lock.unlock(); } // 反例 Lock lock = new XxxLock(); // ... try { // 如果此处抛出异常，则直接执行 finally 代码块 doSomething(); // 无论加锁是否成功，finally 代码块都会执行 lock.lock(); doOthers(); } finally { lock.unlock(); }在使用尝试机制来获取锁的方式中，进入业务代码块之前，必须先判断当前线程是否持有锁。锁的释放规则与锁的阻塞等待方式相同
// 正例 Lock lock = new XxxLock(); // ... boolean isLocked = lock.tryLock(); if (isLocked) { try { doSomething(); doOthers(); } finally { lock.unlock(); } }