程序人生——Java多线程和并发的使用建议

引出

程序人生——Java多线程和并发的使用建议

---

多线程和并发

建议118：不推荐覆写start方法

• 继承自Thread类的多线程类不必覆写start方法。原本的start方法中，调用了本地方法start0，它实现了启动线程、申请栈内存、运行run方法、修改线程状态等职责，线程管理和栈内存管理都是由JVM实现的，如果覆盖了start方法，也就是撤销了线程管理和栈内存管理的能力。所以除非必要，不然不要覆写start方法，即使需要覆写start方法，也需要在方法体内加上super.start调用父类中的start方法来启动默认的线程操作

建议119：启动线程前stop方法是不可靠的

• 现象：使用stop方法停止一个线程，而stop方法在此处的目的不是停止一个线程，而是设置线程为不可启用状态。但是运行结果出现奇怪现象：部分线程还是启动了，也就是在某些线程（没有规律）中的start方法正常执行了。在不符合判断规则的情况下，不可启用状态的线程还是启用了，这是线程启动（start方法）一个缺陷。Thread类的stop方法会根据线程状态来判断是终结线程还是设置线程为不可运行状态，对于未启动的线程（线程状态为NEW）来说，会设置其标志位为不可启动，而其他的状态则是直接停止。start方法源码中，start0方法在stop0方法之前，也就是说即使stopBeforeStart为true（不可启动），也会先启动一个线程，然后再stop0结束这个线程，而罪魁祸首就在这里！所以不要使用stop方法进行状态的设置

建议120：不适用stop方法停止线程

• 线程启动完毕后，需要停止，Java只提供了一个stop方法，但是不建议使用，有以下三个问题：1、stop方法是过时的；2、stop方法会导致代码逻辑不完整，stop方法是一种“恶意”的中断，一旦执行stop方法，即终止当前正在运行的线程，不管线程逻辑是否完整，这是非常危险的，以为stop方法会清除栈内信息，结束该线程，但是可能该线程的一段逻辑非常重，比如子线程的主逻辑、资源回收、情景初始化等，因为stop线程了，这些都不会再执行。子线程执行到何处会被关闭很难定位，这为以后的维护带来了很多麻烦；3、stop方法会破坏原子逻辑，多线程为了解决共享资源抢占的问题，使用了锁概念，避免资源不同步，但是stop方法会丢弃所有的锁，导致原子逻辑受损。Thread提供的interrupt中断线程方法，它不能终止一个正在执行着的线程，它只是修改中断标志唯一。总之，期望终止一个正在运行的线程，不能使用stop方法，需要自行编码实现。如果使用线程池（比如ThreadPoolExecutor类），那么可以通过shutdown方法逐步关闭池中的线程

建议121：线程优先级只使用三个等级

• 线程优先级推荐使用MIN_PRIORITY、NORM_PRIORITY、MAX_PRIORITY三个级别，不建议使用其他7个数字）（线程的优先级（Priority）决定了线程获得CPU运行的机会，优先级越高，运行机会越大。事实：1、并不是严格尊重线程优先级别来执行的，分为10个级别；2、优先级差别越大，运行机会差别越大；对于Java来说，JVM调用操作系统的接口设置优先级，比如Windows是通过调用SetThreadPriority函数来设置的。不同操作系统线程优先级设置是不相同的，Windows有7个优先级，Linux有140个优先级，Freebsd有255个优先级。Java缔造者也发现了该问题，于是在Thread类中设置了三个优先级，建议使用优先级常量，而不是1到10随机的数字

建议122：使用线程异常处理器提升系统可靠性

• 可以使用线程异常处理器来处理相关异常情况的发生，比如当机自动重启，大大提高系统的可靠性。在实际环境中应用注意以下三点：1、共享资源锁定；2、脏数据引起系统逻辑混乱；3、内存溢出，线程异常了，但由该线程创建的对象并不会马上回收，如果再重新启动新线程，再创建一批新对象，特别是加入了场景接管，就危险了，有可能发生OutOfMemory内存泄露问题

建议123：volatile不能保证数据同步