首页 > 代码库 > 多线程设计模式总结(二)
多线程设计模式总结(二)
接上一篇《多线程设计模式总结(一)》，这篇博客再介绍5个多线程设计模式
7)Thread-Per-Message
实现某个方法时创建新线程去完成任务，而不是在本方法里完成任务，这样可提高响应性，因为有些任务比较耗时。
示例程序：
12345678910 | public class Host { private final Handler _handler=new Handler(); public void request(final int count, final char c){ new Thread(){ public void run(){ _handler.handle(count, c); } }.start(); }} |
实现Host类的方法时，新建了一个线程调用Handler对象处理request请求。
每次调用Host对象的request方法时都会创建并启动新线程，这些新线程的启动顺序不是确定的。
适用场景：
适合在操作顺序无所谓时使用，因为请求的方法里新建的线程的启动顺序不是确定的。
在不需要返回值的时候才能使用，因为request方法不会等待线程结束才返回，而是会立即返回，这样得不到请求处理后的结果。
注意事项：
每次调用都会创建并启动一个新线程，对新建线程没有控制权，实际应用中只有很简单的请求才会用Thread-Per-Message这个模式，因为通常我们会关注返回结果，也会控制创建的线程数量，否则系统会吃不消。
8)Worker Thread
在Thread-Per-Message模式里，每次函数调用都会启动一个新线程，但是启动新线程的操作其实是比较繁重的，需要比较多时间，系统对创建的线程数量也会有限制。我们可以预先启动一定数量的线程，组成线程池，每次函数调用时新建一个任务放到任务池，预先启动的线程从任务池里取出任务并执行。这样便可以控制线程的数量，也避免了每次启动新线程的高昂代价，实现了资源重复利用。
示例程序：
Channel类:
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950 | public class Channel { private static final int MAX_REQUEST = 100; private final Request[] _request_queue; private int tail; private int head; private int count; private WorkerThread[] _thread_pool; public Channel(int threads) { _request_queue = new Request[MAX_REQUEST]; tail = 0; head = 0; count = 0; _thread_pool = new WorkerThread[threads]; for (int i = 0; i < threads; i++) { _thread_pool[i] = new WorkerThread("Worker-" + i, this); } } public void startWorkers() { for (int i = 0; i < _thread_pool.length; i++) _thread_pool[i].start(); } public synchronized Request takeRequest() throws InterruptedException { while (count <= 0) { wait(); } Request request = _request_queue[head]; head = (head + 1) % _request_queue.length; count--; notifyAll(); return request; } public synchronized void putRequest(Request request) throws InterruptedException { while (count >= _request_queue.length) { wait(); } _request_queue[tail] = request; tail = (tail + 1) % _request_queue.length; count++; notifyAll(); } } |
WorkerThread类:
1234567891011121314151617181920212223 | public class WorkerThread extends Thread { private final Channel _channel; public WorkerThread(String name, Channel channel) { super(name); _channel = channel; } @Override public void run() { while (true) { Request request; try { request = _channel.takeRequest(); request.execute(); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } } } } |
channel类集成了线程池和任务池，对外提供了startWorkers方法，外界可调用该方法启动所有工作线程，然后通过putRequest方法向任务池添加任务，工作者线程会自动从任务池里取出任务并执行。
适用场景：
和Thread-Per-Message模式一样，Worker Thread模式实现了invocation和exectution的分离，即调用和执行分离，调用者调用方法运行在一个线程，任务的执行在另一个线程。调用者调用方法后可立即返回，提高了程序的响应性。另外也正是因为调用和执行分离了，我们可以控制任务的执行顺序，还可以取消任务，还能分散处理，将任务交给不同的机器执行，如果没有将调用和执行分离，这些特性是无法实现的。
适合有大量任务并且还需要将任务执行分离的程序，比如象应用分发类App，需要经常和服务器通信获取数据，并且通信消息可能还有优先级。
注意事项：
注意控制工作者线程的数量，如果过多，那么会有不少工作者线程并没有工作，会浪费系统资源，如果过少会使得任务池里塞满，导致其它线程长期阻塞。可根据实际工作调整线程数量，和任务池里的最大任务池数。
如果worker thread只有一条，工人线程处理的范围就变成单线程了，可以省去共享互斥的必要。通常GUI框架都是这么实现的，操作界面的线程只有一个，界面元素的方法不需要进行共享互斥。如果操作界面的线程有多个，那么必须进行共享互斥，我们还会经常设计界面元素的子类，子类实现覆盖方法时也必须使用synchronized进行共享互斥，引入共享互斥后会引入锁同步的开销，使程序性能降低，并且如果有不恰当的获取锁的顺序，很容易造成死锁，这使得GUI程序设计非常复杂，故此GUI框架一般都采用单线程。
Java 5的并发包里已经有线程池相关的类，无需自己实现线程池。可使用Executors的方法启动线程池，这些方法包括newFixedThreadPool，newSingleThreadExecutor，newCachedThreadPool，newScheduledThreadPool等等。
9)Future
在Thread-Per-Message模式和Worker Thread模式里，我们实现了调用和执行分离。但是通常我们调用一个函数是可以获得返回值的，在上述两种模式里，虽然实现了调用和执行相分离，但是并不能获取调用执行的返回结果。Future模式则可以获得执行结果，在调用时返回一个Future，可以通过Future获得真正的执行结果。
示例程序：
Host类
123456789101112131415161718 | public class Host { public Data request(final int count, final char c) { System.out.println(" request (" + count + ", " + c + " ) BEGIN"); final FutureData future = new FutureData(); new Thread() { @Override public void run() { RealData realData = http://www.mamicode.com/new RealData(count, c);> |
Data接口
123 | public interface Data { public String getContent();} |
FutureData类
123456789101112131415161718192021222324 | public class FutureData implements Data { private boolean _ready = false; private RealData _real_data = http://www.mamicode.com/null;> |
RealData类
1234567891011121314151617181920212223242526 | public class RealData implements Data { private final String _content; public RealData(int count, char c) { System.out.println("Making Realdata(" + count + "," + c + ") BEGIN"); char[] buffer = new char[count]; for (int i = 0; i < count; i++) { buffer[i] = c; try { Thread.sleep(100); } catch (Exception e) { } } System.out.println(" making Real Data(" + count + "," + c + ") END"); _content = new String(buffer); } @Override public String getContent() { return _content; } } |
适用场景：
如果既想实现调用和执行分离，又想获取执行结果，适合使用Future模式。
Future模式可以获得异步方法调用的”返回值”，分离了”准备返回值”和”使用返回值”这两个过程。
注意事项：
Java 5并发包里已经有Future接口，不仅能获得返回结果，还能取消任务执行。当调用ExecutorService对象的submit方法向任务池提交一个Callable任务后，可获得一个Future对象，用于获取任务执行结果，并可取消任务执行。
10)Two-Phase Termination
这一节介绍如何停止线程，我们刚开始学习线程时，可能很容易犯的错就是调用Thread的stop方法停止线程，该方法确实能迅速停止线程，并会让线程抛出异常。但是调用stop方法是不安全的，如果该线程正获取了某个对象的锁，那么这个锁是不会被释放的，其他线程将继续被阻塞在该锁的条件队列里，并且也许线程正在做的工作是不能被打断的，这样可能会造成系统破坏。从线程角度看，只有执行任务的线程本身知道该何时恰当的停止执行任务，故此我们需要用Two-Phase Termination模式来停止线程，在该模式里如果想停止某个线程，先设置请求线程停止的标志为true，然后调用Thread的interrupt方法，在该线程里每完成一定工作会检查请求线程停止的标志，如果为true，则安全地结束线程。
示例程序：
1234567891011121314151617181920212223242526272829303132333435363738 | public class CountupThread extends Thread { private long counter = 0; private volatile boolean _shutdown_requested = false; public void shutdownRequest() { _shutdown_requested = true; interrupt(); } public boolean isShutdownRequested() { return _shutdown_requested; } @Override public void run() { try { while (!_shutdown_requested) { doWork(); } } catch (InterruptedException e) { e.printStackTrace(); } finally { doShutdown(); } } private void doWork() throws InterruptedException { counter++; System.out.println("doWork: counter = " + counter); Thread.sleep(500); } private void doShutdown() { System.out.println("doShutDown: counter = " + counter); } } |
外界可调用shutdownRequest来停止线程。
适用场景：
需要停止线程时，可考虑使用Two-Phase Termination模式
注意事项：
我们在请求线程停止时，若只设置请求停止标志，是不够的，因为如果线程正在执行sleep操作，那么会等sleep操作执行完后，再执行到检查停止标志的语句才会退出，这样程序响应性不好。
响应停止请求的线程如果只检查中断状态(不是说我们设置的停止标志)也是不够的，如果线程正在sleep或者wait，则会抛出InterruptedException异常，就算没有抛出异常，线程也会变成中断状态，似乎我们没必要设置停止标志，只需检查InterruptedException或者用isInterrupted方法检查当前线程的中断状态就可以了，但是这样做会引入潜在的危险，如果该线程调用的方法忽略了InterruptedException，或者该线程使用的对象的某个方法忽略了InterruptedException，而这样的情况是很常见的，尤其是如果我们使用某些类库代码时，又不知其实现，即使忽略了InterruptedException，我们也不知道，在这种情况下，我们无法检查到是否有其它线程正在请求本线程退出，故此说设置终端标志是有必要的，除非能保证线程所引用的所有对象(包括间接引用的)不会忽略InterruptedException，或者能保存中断状态。
中断状态和InterruptedException可以互转:
1) 中断状态 -> InterruptedException
- 1) 中断状态 -> InterruptedException
123 | if(Thread.interrupted){throw new InterruptedException()} |
- 2) InterruptedException -> 中断状态
12345 | try{ Thread.sleep(1000);}catch (InterruptedException e) { Thread.currentThread().interrupt();} |
- 3) InterruptedException -> InterruptedException
12345678910 | InterruptedException savedInterruptException = null;...try{ Thread.sleep(1000);}catch (InterruptedException e) { savedInterruptException=e;}...if(savedInterruptException != null ) throw savedInterruptException; |
11)Thread-Specific Storage
我们知道，如果一个对象不会被多个线程访问，那么就不存在线程安全问题。Thread-Specific Storage模式就是这样一种设计模式，为每个线程生成单独的对象，解决线程安全问题。不过为线程生成单独的对象这些细节对于使用者来说是隐藏的，使用者只需简单使用即可。需要用到ThreadLocal类，它是线程保管箱，为每个线程保存单独的对象。
示例程序：
Log类
123456789101112131415161718192021222324 | public class Log { private static ThreadLocal<TSLog> _ts_log_collection = new ThreadLocal<TSLog>(); public static void println(String s) { getTSLog().println(s); } public static void close() { getTSLog().close(); } private static TSLog getTSLog() { TSLog tsLog = _ts_log_collection.get(); if (tsLog == null) { tsLog = new TSLog( Thread.currentThread().getName() + "-log.txt" ); _ts_log_collection.set(tsLog); } return tsLog; } } |
TSLog类
12345678910111213141516171819 | public class TSLog { private PrintWriter _writer = null; public TSLog(String fileName) { try { _writer = new PrintWriter(fileName); } catch (FileNotFoundException e) { e.printStackTrace(); } } public void println(String s) { _writer.write(s); } public void close() { _writer.close(); }} |
适用场景：
使用Thread-Specific Storgae模式可很好的解决多线程安全问题，每个线程都有单独的对象，如果从ThreadLocal类里获取线程独有对象的时间远小于调用对象方法的执行时间，可提高程序性能。因此在日志系统里如果可以为每个线程建立日志文件，那么特别适合使用Thread-Specific Storage模式。
注意事项：
采用Thread-Specific Storage模式意味着将线程特有信息放在线程外部，在示例程序里，我们将线程特有的TSLog放在了ThreadLocal的实例里。通常我们一般将线程特有的信息放在线程内部，比如建立一个Thread类的子类MyThread，我们声明的MyThread的字段，就是线程特有的信息。因为把线程特有信息放在线程外部，每个线程访问线程独有信息时，会取出自己独有信息，但是调试时会困难一些，因为有隐藏的context(当前线程环境)， 程序以前的行为，也可能会使context出现异常，而是造成现在的bug的真正原因，我们比较难找到线程先前的什么行为导致context出现异常。
设计多线程程序，主体是指主动操作的对象，一般指线程，客体指线程调用的对象，一般指的是任务对象，会因为重点放在“主体”与“客体”的不同，有两种开发方式：
- 1) Actor-based 注重主体
- 2) Task-based 注重客体
Actor-based 注重主体，偏重于线程，由线程维护状态，将工作相关的信息都放到线程类的字段，类似这样
123456 | class Actor extends Thread{操作者内部的状态public void run(){ 从外部取得任务，改变自己内部状态的循环}} |
Task-based注重客体，将状态封装到任务对象里，在线程之间传递这些任务对象，这些任务对象被称为消息，请求或者命令。使用这种开发方式的最典型的例子是Worker Thread 模式，生产者消费者模式。任务类似这样:
123456 | class Task implements Runnable{ 执行任务所需的信息 public void run(){ 执行任务所需的处理内容 }} |
实际上这两个开发方式是混用的，本人刚设计多线程程序时，总是基于Actor-based的思维方式，甚至在解决生产者消费者问题时也使用Actor-based思维方式，造成程序结构混乱，因此最好按实际场景来，适合使用Actor-based开发方式的就使用Actor-based，适合Task-based开发方式的就使用Task-based。
转载 http://www.cloudchou.com/softdesign/post-616.html
多线程设计模式总结(二)