多线程设计模式总结(二)

接上一篇《多线程设计模式总结(一)》，这篇博客再介绍5个多线程设计模式

7)Thread-Per-Message

实现某个方法时创建新线程去完成任务，而不是在本方法里完成任务，这样可提高响应性，因为有些任务比较耗时。

示例程序：

1
2
3
4
5
6
7
8
9
10

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类:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

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类:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

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类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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 = new RealData(count, c);
				future.setRealData(realData);
			}
 
		}.start();
		return future;
	}
 
}

Data接口

1
2
3

public interface Data {
	public String getContent();
}

FutureData类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class FutureData implements Data {
	private boolean _ready = false;
	private RealData _real_data = null;
 
	public synchronized void setRealData(RealData realData) {
		if (_ready)
			return;
		_real_data = realData;
		_ready = true;
		notifyAll();
	}
 
	@Override
	public synchronized String getContent() {
		while (!_ready) {
			try {
				wait();
			} catch (InterruptedException e) {
			}
		}
		return _real_data.getContent();
	}
 
}

RealData类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

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，则安全地结束线程。

示例程序：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

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
1
2
3

if(Thread.interrupted){
throw new InterruptedException()
}
    • 2) InterruptedException -> 中断状态
1
2
3
4
5

try{
	Thread.sleep(1000);
}catch (InterruptedException e) {
	Thread.currentThread().interrupt();
}
    • 3) InterruptedException -> InterruptedException
1
2
3
4
5
6
7
8
9
10

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类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

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类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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 注重主体，偏重于线程，由线程维护状态，将工作相关的信息都放到线程类的字段，类似这样

1
2
3
4
5
6

class Actor extends Thread{
操作者内部的状态
public void run(){
 从外部取得任务，改变自己内部状态的循环
}
}

Task-based注重客体，将状态封装到任务对象里，在线程之间传递这些任务对象，这些任务对象被称为消息，请求或者命令。使用这种开发方式的最典型的例子是Worker Thread 模式，生产者消费者模式。任务类似这样:

1
2
3
4
5
6

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

时间： 2024-10-19 09:10:12

多线程设计模式总结(二)的相关文章

多线程设计模式总结(三)

接上一篇<多线程设计模式总结(二)>,这篇博客再聊一下最复杂的Active Object模式 12)Active Object Active Object模式,也称为Actor模式.Active Object即主动对象,它不仅拥有独立线程,并且可以从外部接收异步消息,并能配合需要返回处理结果.这里的Active Object不是指一个对象,而是指将一群对象组织起来,对外表现为一个整体,这个整体拥有独立线程,并能接收外部的异步消息,这个整体(Active Object)处理完异步消息后还可以返回

java设计模式（二）单例模式 建造者模式

(三)单例模式 单例模式应该是最常见的设计模式,作用是保证在JVM中,该对象只有一个实例存在. 优点:1.减少某些创建比较频繁的或者比较大型的对象的系统开销. 2.省去了new操作符,降低系统内存使用频率,减轻GC压力. 3.保证核心代码的唯一性,比如交易引擎. 单例模式看似是最简单的设计模式. public class Singleton { //私有构造方法,防止实例化 private Singleton(){ } //创建类的实例的时候加载 private static Factory f

多线程设计模式——Read-Write Lock模式和Future模式分析

目录 多线程程序评价标准 任何模式都有一个相同的"中心思想" Read-Write Lock 模式 RW-Lock模式特点 冲突总结 手搓RW Lock模式代码 类图 Data类 P.S. Before/After模式 ReadWriteLock类 正确运行结果 适用场合 "逻辑锁"vs"物理锁" 性能对比 "中心思想"分析 Future 模式 Future模式特点 手搓Future模式代码 类图 Main类 Host类 Fu

并行设计模式（二）-- Master-Worker模式

Java多线程编程中,常用的多线程设计模式包括:Future模式.Master-Worker模式.Guarded Suspeionsion模式.不变模式和生产者-消费者模式等.这篇文章主要讲述Master-Worker模式,关于其他多线程设计模式的地址如下: 关于Future模式的详解:并行设计模式(一)-- Future模式 关于Guarded Suspeionsion模式的详解:并行设计模式(三)-- Guarded Suspeionsion模式 关于不变模式的详解:并行设计模式(四)--

Java设计模式（二）-单例模式

单例模式建议保证某个对象仅仅只有一个实例,当只有一个对象来协调整个系统的操作时,在计算机系统中,线程池.缓存.日志对象.对话框.打印机.显卡的驱动程序对象常被设计成单例,总之,选择单例模式就是为了避免不一致状态,避免政出多头. 下面是单例模式的类图:包括的private和static修饰的实例instance.一个private的构造函数.一个static的getInstance函数 单例模式主要有三种:懒汉式单例.饿汉式单例.登记式单例三种 1.饿汉式单例:在类的初始化时候,自行创建了实例 c

设计模式（二）学习----动态代理

动态代理:动态代理是指在实现阶段不需要关心代理谁,而在运行阶段才指定代理哪一个对象.Spring AOP采用的核心思想就是动态代理设计模式.  下面看动态代理的UML类图: 下面思考问题:invocationHandler的invoke方法是由谁来调用的,代理对象是怎么生成的? 动态代理类: package com.lp.ecjtu.DynamicProxy; import java.lang.reflect.InvocationHandler; import java.lang.reflect

Android多线程分析之二：Thread的实现

Android多线程分析之二:Thread 罗朝辉 (http://blog.csdn.net/kesalin) CC 许可,转载请注明出处 在前文<Android多线程分析之一:使用Thread异步下载图像>中演示了如何使用 Thread 处理异步事务.示例中这个 Java Thread 类都是位于 Framework 层的类,它自身是通过 JNI 转调 dalvik 里面的 Thread 相关方法实现的.因此要分析 Androd 中的线程,就需要分析这两层中的与线程相关的代码,这就是本文要

IOS设计模式之二（门面模式，装饰器模式）

本文原文请见:http://www.raywenderlich.com/46988/ios-design-patterns. 由 @krq_tiger(http://weibo.com/xmuzyq)翻译,如果你发现有什么错误,请与我联系谢谢. 门面(Facade)模式(译者注:facade有些书籍译为门面,有些书籍译为外观,此处译为门面) 门面模式针对复杂的子系统提供了单一的接口,不需要暴漏一些列的类和API给用户,你仅仅暴漏一个简单统一的API. 下面的图解释了这个概念: 这个API的使用者

java多线程设计模式

java语言已经内置了多线程支持,所有实现Runnable接口的类都可被启动一个新线程,新线程会执行该实例的run()方法,当run()方法执行完毕后,线程就结束了.一旦一个线程执行完毕,这个实例就不能再重新启动,只能重新生成一个新实例,再启动一个新线程. Thread类是实现了Runnable接口的一个实例,它代表一个线程的实例,并且,启动线程的唯一方法就是通过Thread类的start()实例方法: Thread t = new Thread(); t.start(); start()方法是