这篇文章是对《Java并发编程实战》1.3节中线程的风险的思考。
安全性问题
使用多线程带来的最糟糕的问题就是安全性问题。书中以一个线程不安全的UnsafeSequence类为例：
publicclassUnsafeSequence{privateintvalue;/** * 返回一个唯一的数值 *@return*/publicintgetNext(){returnvalue++; }publicintgetValue(){returnvalue; }}复制代码
这个类在单线程的情况下能正常工作，但是在多线程的情况下就有可能不正常。需要注意的是，线程的安全性问题描述的是在多线程情况下有可能会带来安全性问题，并非一定就有安全性问题。比如，下面这段代码使用两个线程调用UnsafeSequence的getNext()方法。
publicclassNextValueThreadextendsThread{privateUnsafeSequence unsafeSequence;publicNextValueThread(UnsafeSequence unsafeSequence){this.unsafeSequence = unsafeSequence; }@Overridepublicvoidrun(){ unsafeSequence.getNext(); }publicstaticvoidmain(String[] args){ UnsafeSequence unsafeSequence =newUnsafeSequence();// 使用2个线程NextValueThread[] nextValueThread =newNextValueThread[2];for(inti =0; i < nextValueThread.length; i++) { nextValueThread[i] =newNextValueThread(unsafeSequence); nextValueThread[i].start(); }for(inti =0; i < nextValueThread.length; i++) {try{ nextValueThread[i].join(); }catch(InterruptedException e) { e.printStackTrace(); } } System.out.println(unsafeSequence.getValue()); }}复制代码
上面的代码尽管使用了这个不安全的类，但是它在大部分测试得到的结果都是正常的。
活跃性问题
多线程会带来的另外一个问题就是活跃性问题。活跃性问题，包括死锁，饥饿，活锁。
死锁
死锁的一个著名例子就是哲学家就餐问题，有5个哲学家吃中餐，总共只有5根筷子，筷子按下图的顺序摆放。
每个哲学家就餐时都先拿左边筷子再拿右边筷子，如果没有拿到右边筷子，左边的筷子也不会放下，当每个人左手都拿到筷子时，因为右手筷子都被另外一个人拿到了，结果就是一直拿不到一双筷子，大家都被饿死。要形成死锁有四个必要的条件：互斥，请求与保持，循环等待，不可剥夺，以哲学家用餐的例子来说：
互斥：资源不能被共享，只能被一个线程持有（一根筷子只能被一个哲学家持有）
请求与保持：已经拿到资源的线程会再次请求新的资源，并不会释放已经拿到的资源（左手拿到筷子的哲学家右手也会去拿筷子，并且不会放下左手已经拿到的筷子）
不可剥夺：已经被分配的资源，不能从拥有资源的线程中强制剥夺（筷子在哲学家手里后，其它哲学家不能抢）
循环等待：所有线程等待资源形成闭环（五个哲学家每个人右边的筷子都被下一个人的左手拿着，形成闭环）
哲学家就餐demo：github.com/linnanc/con…
活锁
如果哲学家在拿到筷子后的一段时间内选择放下左手已经拿住的筷子，也就破坏了请求与保持的条件，这样死锁就不会发生了。但是仍然可能发生活锁的现象。比如每个哲学家拿到左边筷子后等一段时间没有等到右边的筷子，然后他们都放下左边的筷子，一段时间后，他们又都拿起左边的筷子，继续等右边的筷子。这样造成一直循环重复的问题就是活锁。
饥饿
由于线程调度时，会优先调度高优先级的线程，有些低优先级的线程可能永远都得不到执行，这就是饥饿。例如5个哲学家中某个哲学家拿筷子的动作远没有其它的哲学家快，这就可能永远拿不到筷子，造成饥饿。
性能问题
在多线程程序中，当线程调度器临时挂起活跃的线程并转而运行另一个线程就会进行上下文切换，上下文切换因为操作系统要在用户态和内核态进行切换，会带来很大的开销：保存和恢复执行上下文，丢失局部性。如果只是在多线程中执行很简单的任务，那很有可能CPU时间更多的花在线程调度上，而不是线程运行上，这样更得不偿失。
