轻松使用线程: 不共享有时是最好的
2013-07-30 17:13
302 查看
编写线程安全类是困难的。它不但要求仔细分析在什么条件可以对变量进行读写,而且要求仔细分析其它类能如何使用某个类。 有时,要在不影响类的功能、易用性或性能的情况下使类成为线程安全的是很困难的。有些类保留从一个方法调用到下一个方法调用的状态信息,要在实践中使这样的类成为线程安全的是困难的。
管理非线程安全类的使用比试图使类成为线程安全的要更容易些。非线程安全类通常可以安全地在多线程程序中使用,只要您能确保一个线程所用的类的实例不被其它线程使用。例如,JDBC
不使用
什么是线程局部变量(thread-local variable)?
线程局部变量高效地为每个使用它的线程提供单独的线程局部变量值的副本。每个线程只能看到与自己相联系的值,而不知道别的线程可能正在使用或修改它们自己的副本。一些编译器(例如 Microsoft Visual C++ 编译器或 IBM XL FORTRAN 编译器)用存储类别修饰符(像
因为线程局部变量是通过一个类来实现的,而不是作为 Java 语言本身的一部分,所以 Java 语言线程局部变量的使用语法比内建线程局部变量语言的使用语法要笨拙一些。要创建一个线程局部变量,请实例化类
清单 1. ThreadLocal 接口
清单 2. ThreadLocal 的糟糕实现
这个实现的性能不会很好,因为每个
回页首
用 ThreadLocal 实现每线程 Singleton
线程局部变量常被用来描绘有状态“单子”(Singleton) 或线程安全的共享对象,或者是通过把不安全的整个变量封装进
清单 3. 把一个 JDBC 连接存储到一个每线程 Singleton 中
任何创建的花费比使用的花费相对昂贵些的有状态或非线程安全的对象,例如 JDBC
回页首
用 ThreadLocal 简化调试日志纪录
其它适合使用
清单 4. 用 ThreadLocal 管理每线程调试日志
在您的代码中,您可以调用
回页首
ThreadLocal 的线程安全性稍差的堂兄弟,InheritableThreadLocal
ThreadLocal 类有一个亲戚,InheritableThreadLocal,它以相似的方式工作,但适用于种类完全不同的应用程序。创建一个线程时如果保存了所有
回页首
ThreadLocal 的性能
虽然线程局部变量早已赫赫有名并被包括 Posix
在 JDK 1.2 中,
Java 平台版本 1.3 提供的
不幸的是,即使有了这些改进,Java 1.3 中的
在 Java 平台的最新版本,即版本 1.4b2 中,
回页首
ThreadLocal 的好处
管理非线程安全类的使用比试图使类成为线程安全的要更容易些。非线程安全类通常可以安全地在多线程程序中使用,只要您能确保一个线程所用的类的实例不被其它线程使用。例如,JDBC
Connection类是非线程安全的 — 两个线程不能在小粒度级上安全地共享一个
Connection— 但如果每个线程都有它自己的
Connection,那么多个线程就可以同时安全地进行数据库操作。
不使用
ThreadLocal为每个线程维护一个单独的 JDBC 连接(或任何其它对象)当然是可能的;Thread API 给了我们把对象和线程联系起来所需的所有工具。而 ThreadLocal 则使我们能更容易地把线程和它的每线程(per-thread)数据成功地联系起来。
什么是线程局部变量(thread-local variable)?
线程局部变量高效地为每个使用它的线程提供单独的线程局部变量值的副本。每个线程只能看到与自己相联系的值,而不知道别的线程可能正在使用或修改它们自己的副本。一些编译器(例如 Microsoft Visual C++ 编译器或 IBM XL FORTRAN 编译器)用存储类别修饰符(像
static或
volatile)把对线程局部变量的支持集成到了其语言中。Java 编译器对线程局部变量不提供特别的语言支持;相反地,它用
ThreadLocal类实现这些支持,
核心 Thread类中有这个类的特别支持。
因为线程局部变量是通过一个类来实现的,而不是作为 Java 语言本身的一部分,所以 Java 语言线程局部变量的使用语法比内建线程局部变量语言的使用语法要笨拙一些。要创建一个线程局部变量,请实例化类
ThreadLocal的一个对象。
ThreadLocal类的行为与
java.lang.ref中的各种
Reference类的行为很相似;
ThreadLocal类充当存储或检索一个值时的间接句柄。清单 1 显示了
ThreadLocal接口。
清单 1. ThreadLocal 接口
public class ThreadLocal { public Object get(); public void set(Object newValue); public Object initialValue(); } |
get()访问器检索变量的当前线程的值;
set()访问器修改当前线程的值。
initialValue()方法是可选的,如果线程未使用过某个变量,那么您可以用这个方法来设置这个变量的初始值;它允许延迟初始化。用一个示例实现来说明 ThreadLocal 的工作方式是最好的方法。清单 2 显示了
ThreadLocal的一个实现方式。它不是一个特别好的实现(虽然它与最初实现非常相似),所以很可能性能不佳,但它清楚地说明了 ThreadLocal 的工作方式。
清单 2. ThreadLocal 的糟糕实现
public class ThreadLocal { private Map values = Collections.synchronizedMap(new HashMap()); public Object get() { Thread curThread = Thread.currentThread(); Object o = values.get(curThread); if (o == null && !values.containsKey(curThread)) { o = initialValue(); values.put(curThread, o); } return o; } public void set(Object newValue) { values.put(Thread.currentThread(), newValue); } public Object initialValue() { return null; } } |
get()和
set()操作都需要
values映射表上的同步,而且如果多个线程同时访问同一个
ThreadLocal,那么将发生争用。此外,这个实现也是不切实际的,因为用
Thread对象做
values映射表中的关键字将导致无法在线程退出后对
Thread进行垃圾回收,而且也无法对死线程的
ThreadLocal的特定于线程的值进行垃圾回收。
回页首
用 ThreadLocal 实现每线程 Singleton
线程局部变量常被用来描绘有状态“单子”(Singleton) 或线程安全的共享对象,或者是通过把不安全的整个变量封装进
ThreadLocal,或者是通过把对象的特定于线程的状态封装进
ThreadLocal。例如,在与数据库有紧密联系的应用程序中,程序的很多方法可能都需要访问数据库。在系统的每个方法中都包含一个
Connection作为参数是不方便的 — 用“单子”来访问连接可能是一个虽然更粗糙,但却方便得多的技术。然而,多个线程不能安全地共享一个 JDBC
Connection。如清单 3 所示,通过使用“单子”中的
ThreadLocal,我们就能让我们的程序中的任何类容易地获取每线程
Connection的一个引用。这样,我们可以认为
ThreadLocal允许我们创建 每线程单子。
清单 3. 把一个 JDBC 连接存储到一个每线程 Singleton 中
public class ConnectionDispenser { private static class ThreadLocalConnection extends ThreadLocal { public Object initialValue() { return DriverManager.getConnection(ConfigurationSingleton.getDbUrl()); } } private ThreadLocalConnection conn = new ThreadLocalConnection(); public static Connection getConnection() { return (Connection) conn.get(); } } |
Connection或正则表达式匹配器,都是可以使用每线程单子(singleton)技术的好地方。当然,在类似这样的地方,您可以使用其它技术,例如用池,来安全地管理共享访问。然而,从可伸缩性角度看,即使是用池也存在一些潜在缺陷。因为池实现必须使用同步,以维护池数据结构的完整性,如果所有线程使用同一个池,那么在有很多线程频繁地对池进行访问的系统中,程序性能将因争用而降低。
回页首
用 ThreadLocal 简化调试日志纪录
其它适合使用
ThreadLocal但用池却不能成为很好的替代技术的应用程序包括存储或累积每线程上下文信息以备稍后检索之用这样的应用程序。例如,假设您想创建一个用于管理多线程应用程序调试信息的工具。您可以用如清单 4 所示的
DebugLogger类作为线程局部容器来累积调试信息。在一个工作单元的开头,您清空容器,而当一个错误出现时,您查询该容器以检索这个工作单元迄今为止生成的所有调试信息。
清单 4. 用 ThreadLocal 管理每线程调试日志
public class DebugLogger { private static class ThreadLocalList extends ThreadLocal { public Object initialValue() { return new ArrayList(); } public List getList() { return (List) super.get(); } } private ThreadLocalList list = new ThreadLocalList(); private static String[] stringArray = new String[0]; public void clear() { list.getList().clear(); } public void put(String text) { list.getList().add(text); } public String[] get() { return list.getList().toArray(stringArray); } } |
DebugLogger.put()来保存您的程序正在做什么的信息,而且,稍后如果有必要(例如发生了一个错误),您能够容易地检索与某个特定线程相关的调试信息。 与简单地把所有信息转储到一个日志文件,然后努力找出哪个日志记录来自哪个线程(还要担心线程争用日志纪录对象)相比,这种技术简便得多,也有效得多。
ThreadLocal在基于 servlet 的应用程序或工作单元是一个整体请求的任何多线程应用程序服务器中也是很有用的,因为在处理请求的整个过程中将要用到单个线程。您可以通过前面讲述的每线程单子技术用
ThreadLocal变量来存储各种每请求(per-request)上下文信息。
回页首
ThreadLocal 的线程安全性稍差的堂兄弟,InheritableThreadLocal
ThreadLocal 类有一个亲戚,InheritableThreadLocal,它以相似的方式工作,但适用于种类完全不同的应用程序。创建一个线程时如果保存了所有
InheritableThreadLocal对象的值,那么这些值也将自动传递给子线程。如果一个子线程调用
InheritableThreadLocal的
get(),那么它将与它的父线程看到同一个对象。为保护线程安全性,您应该只对不可变对象(一旦创建,其状态就永远不会被改变的对象)使用
InheritableThreadLocal,因为对象被多个线程共享。
InheritableThreadLocal很合适用于把数据从父线程传到子线程,例如用户标识(user id)或事务标识(transaction id),但不能是有状态对象,例如 JDBC
Connection。
回页首
ThreadLocal 的性能
虽然线程局部变量早已赫赫有名并被包括 Posix
pthreads规范在内的很多线程框架支持,但最初的 Java 线程设计中却省略了它,只是在 Java 平台的版本 1.2 中才添加上去。在很多方面,
ThreadLocal仍在发展之中;在版本 1.3 中它被重写,版本 1.4 中又重写了一次,两次都专门是为了性能问题。
在 JDK 1.2 中,
ThreadLocal的实现方式与清单 2 中的方式非常相似,除了用同步
WeakHashMap代替
HashMap来存储 values 之外。(以一些额外的性能开销为代价,使用 WeakHashMap 解决了无法对 Thread 对象进行垃圾回收的问题。)不用说,
ThreadLocal的性能是相当差的。
Java 平台版本 1.3 提供的
ThreadLocal版本已经尽量更好了;它不使用任何同步,从而不存在可伸缩性问题,而且它也不使用弱引用。相反地,人们通过给
Thread添加一个实例变量(该变量用于保存当前线程的从线程局部变量到它的值的映射的
HashMap)来修改
Thread类以支持
ThreadLocal。因为检索或设置一个线程局部变量的过程不涉及对可能被另一个线程读写的数据的读写操作,所以您可以不用任何同步就实现
ThreadLocal.get()和
set()。而且,因为每线程值的引用被存储在自已的
Thread对象中,所以当对
Thread进行垃圾回收时,也能对该
Thread的每线程值进行垃圾回收。
不幸的是,即使有了这些改进,Java 1.3 中的
ThreadLocal的性能仍然出奇地慢。据我的粗略测量,在双处理器 Linux 系统上的 Sun 1.3 JDK 中进行
ThreadLocal.get()操作,所耗费的时间大约是无争用同步的两倍。性能这么差的原因是
Thread.currentThread()方法的花费非常大,占了
ThreadLocal.get()运行时间的三分之二还多。虽然有这些缺点,JDK 1.3
ThreadLocal.get()仍然比争用同步快得多,所以如果在任何存在严重争用的地方(可能是有非常多的线程,或者同步块被频繁地执行,或者同步块很大),
ThreadLocal可能仍然要高效得多。
在 Java 平台的最新版本,即版本 1.4b2 中,
ThreadLocal和
Thread.currentThread()的性能都有了很大提高。有了这些提高,
ThreadLocal应该比其它技术,如用池,更快。由于它比其它技术更简单,也更不易出错,人们最终将发现它是避免线程间出现不希望的交互的有效途径。
回页首
ThreadLocal 的好处
ThreadLocal能带来很多好处。它常常是把有状态类描绘成线程安全的,或者封装非线程安全类以使它们能够在多线程环境中安全地使用的最容易的方式。使用
ThreadLocal使我们可以绕过为实现线程安全而对何时需要同步进行判断的复杂过程,而且因为它不需要任何同步,所以也改善了可伸缩性。除简单之外,用
ThreadLocal存储每线程单子或每线程上下文信息在归档方面还有一个颇有价值好处 — 通过使用
ThreadLocal,存储在
ThreadLocal中的对象都是 不被线程共享的是清晰的,从而简化了判断一个类是否线程安全的工作。
相关文章推荐
- 轻松使用线程: 不共享有时是最好的
- 轻松使用线程: 不共享有时是最好的
- 轻松使用线程: 不共享有时是最好的
- 轻松使用线程: 不共享有时是最好的 from ibm developerworks
- 轻松使用线程: 不共享有时是最好的——利用 ThreadLocal 提高可伸缩性
- 轻松使用线程: 减少争用——抛开您自己的习惯,提高应用程序的性能
- 线程使用共享堆而非私有堆的原因分析
- Android中轻松使用线程
- ThreadLocal的使用,保证每一个线程都有自己的共享变量。
- Java线程(二):线程数据共享及ThreadLocal使用
- 安卓启动界面源码共享,使用线程实现的!
- android 线程范围内共享变量以及ThreadLocal的使用
- 共享内存与同步线程的使用例子
- (三) Java多线程详解之线程范围内共享变量及ThreadLocal类使用
- 详解 Qt 线程间共享数据(使用signal/slot传递数据,线程间传递信号会立刻返回,但也可通过connect改变)
- java 使用volatile实现线程数据的共享
- 使用ACE互斥,同步线程共享的数据资源
- python:线程的使用、线程共享全局变量、列表作为参数(全局变量)、避免全局变量被修改
- 轻松使用线程: 同步不是敌人
- java多线程-Semaphore信号量使用 介绍 信号量(Semaphore),有时被称为信号灯,是在多线程环境下使用的一种设施, 它负责协调各个线程, 以保证它们能够正确、合理的使用公共资源