http://ajava.org/course/java/15970.html
什么是线程局部变量(thread-local variable)?轻松使用线程: 不共享有时是最好的
ThreadLocal
类是悄悄地出现在 Java 平台版本 1.2 中的。虽然支持线程局部变量早就是许多线程工具(例如 Posixpthreads
工具)的一部分,但 Java Threads API 的最初设计却没有这项有用的功能。而且,最初的实现也相当低效。由于这些原因,ThreadLocal
极少受到关注,但对简化线程安全并发程序的开发来说,它却是很方便的。在 轻松使用线程的第 3 部分,Java 软件顾问 Brian Goetz 研究了ThreadLocal
并提供了一些使用技巧。参加 Brian 的 多线程 Java 编程讨论论坛以获得您工程中的线程和并发问题的帮助。
编写线程安全类是困难的。它不但要求仔细分析在什么条件可以对变量进行读写,而且要求仔细分析其它类能如何使用某个 类。 有时,要在不影响类的功能、易用性或性能的情况下使类成为线程安全的是很困难的。有些类保留从一个方法调用到下一个方法调用的状态信息,要在实践中使这样 的类成为线程安全的是困难的。
管理非线程安全类的使用比试图使类成为线程安全的要更容易些。非线程安全类通常可以安全地在多线程程序中使用,只要 您能确保一个线程所用的类的实例不被其它线程使用。例如,JDBC Connection
类是非线程安全的 — 两个线程不能在小粒度级上安全地共享一个 Connection
— 但如果每个线程都有它自己的 Connection
,那么多个线程就可以同时安全地进行数据库操作。
不使用 ThreadLocal
为每个线程维护一个单独的 JDBC 连接(或任何其它对象)当然是可能的;Thread API 给了我们把对象和线程联系起来所需的所有工具。而 ThreadLocal 则使我们能更容易地把线程和它的每线程(per-thread)数据成功地联系起来。
线程局部变量高效地为每个使用它的线程提供单独的线程局部变量值的副本。每个线程只能看到与自己 相联系的值,而不知道别的线程可能正在使用或修改它们自己的副本。一些编译器(例如 Microsoft Visual C++ 编译器或 IBM XL FORTRAN 编译器)用存储类别修饰符(像 static
或 volatile
)把对线程局部变量的支持集成到了其语言中。Java 编译器对线程局部变量不提供特别的语言支持;相反地,它用 ThreadLocal
类实现这些支持, 核心 Thread
类中有这个类的特别支持。
因为线程局部变量是通过一个类来实现的,而不是作为 Java 语言本身的一部分,所以 Java 语言线程局部变量的使用语法比内建线程局部变量语言的使用语法要笨拙一些。要创建一个线程局部变量,请实例化类 ThreadLocal
的一个对象。 ThreadLocal
类的行为与 java.lang.ref
中的各种 Reference
类的行为很相似; ThreadLocal
类充当存储或检索一个值时的间接句柄。清单 1 显示了 ThreadLocal
接口。
清单 1. ThreadLocal 接口
|
get()
访问器检索变量的当前线程的值; set()
访问器修改当前线程的值。 initialValue()
方法是可选的,如果线程未使用过某个变量,那么您可以用这个方法来设置这个变量的初始值;它允许延迟初始化。用一个示例实现来说明 ThreadLocal 的工作方式是最好的方法。清单 2 显示了 ThreadLocal
的一个实现方式。它不是一个特别好的实现(虽然它与最初实现非常相似),所以很可能性能不佳,但它清楚地说明了 ThreadLocal 的工作方式。
清单 2. ThreadLocal 的糟糕实现
|
这个实现的性能不会很好,因为每个 get()
和 set()
操作都需要 values
映射表上的同步,而且如果多个线程同时访问同一个 ThreadLocal
,那么将发生争用。此外,这个实现也是不切实际的,因为用 Thread
对象做 values
映射表中的关键字将导致无法在线程退出后对 Thread
进行垃圾回收,而且也无法对死线程的 ThreadLocal
的特定于线程的值进行垃圾回收。
线程局部变量常被用来描绘有状态“单子”(Singleton) 或线程安全的共享对象,或者是通过把不安全的整个变量封装进 ThreadLocal
,或者是通过把对象的特定于线程的状态封装进 ThreadLocal
。例如,在与数据库有紧密联系的应用程序中,程序的很多方法可能都需要访问数据库。在系统的每个方法中都包含一个 Connection
作为参数是不方便的 — 用“单子”来访问连接可能是一个虽然更粗糙,但却方便得多的技术。然而,多个线程不能安全地共享一个 JDBC Connection
。如清单 3 所示,通过使用“单子”中的 ThreadLocal
,我们就能让我们的程序中的任何类容易地获取每线程 Connection
的一个引用。这样,我们可以认为 ThreadLocal
允许我们创建 每线程单子。
清单 3. 把一个 JDBC 连接存储到一个每线程 Singleton 中
|
任何创建的花费比使用的花费相对昂贵些的有状态或非线程安全的对象,例如 JDBC Connection
或正则表达式匹配器,都是可以使用每线程单子(singleton)技术的好地方。当然,在类似这样的地方,您可以使用其它技术,例如用池,来安全地管理 共享访问。然而,从可伸缩性角度看,即使是用池也存在一些潜在缺陷。因为池实现必须使用同步,以维护池数据结构的完整性,如果所有线程使用同一个池,那么 在有很多线程频繁地对池进行访问的系统中,程序性能将因争用而降低。
其它适合使用 ThreadLocal
但用池却不能成为很好的替代技术的应用程序包括存储或累积每线程上下文信息以备稍后检索之用这样的应用程序。例如,假设您想创建一个用于管理多线程应用程 序调试信息的工具。您可以用如清单 4 所示的 DebugLogger
类作为线程局部容器来累积调试信息。在一个工作单元的开头,您清空容器,而当一个错误出现时,您查询该容器以检索这个工作单元迄今为止生成的所有调试信 息。
清单 4. 用 ThreadLocal 管理每线程调试日志
|
在您的代码中,您可以调用 DebugLogger.put()
来保存您的程序正在做什么的信息,而且,稍后如果有必要(例如发生了一个错误),您能够容易地检索与某个特定线程相关的调试信息。 与简单地把所有信息转储到一个日志文件,然后努力找出哪个日志记录来自哪个线程(还要担心线程争用日志纪录对象)相比,这种技术简便得多,也有效得多。
ThreadLocal
在基于 servlet 的应用程序或工作单元是一个整体请求的任何多线程应用程序服务器中也是很有用的,因为在处理请求的整个过程中将要用到单个线程。您可以通过前面讲述的每线 程单子技术用 ThreadLocal
变量来存储各种每请求(per-request)上下文信息。
ThreadLocal 的线程安全性稍差的堂兄弟,InheritableThreadLocal
ThreadLocal 类有一个亲戚,InheritableThreadLocal,它以相似的方式工作,但适用于种类完全不同的应用程序。创建一个线程时如果保存了所有 InheritableThreadLocal
对象的值,那么这些值也将自动传递给子线程。如果一个子线程调用 InheritableThreadLocal
的 get()
,那么它将与它的父线程看到同一个对象。为保护线程安全性,您应该只对不可变对象(一旦创建,其状态就永远不会被改变的对象)使用 InheritableThreadLocal
,因为对象被多个线程共享。 InheritableThreadLocal
很合适用于把数据从父线程传到子线程,例如用户标识(user id)或事务标识(transaction id),但不能是有状态对象,例如 JDBC Connection
。
虽然线程局部变量早已赫赫有名并被包括 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
中的对象都是 不被线程共享的是清晰的,从而简化了判断 一个类是否线程安全的工作。
1 comment:
不每個條件 可用吃東西 空間換取時間
http://www.blogger.com/profile-find.g?t=l&loc0=TW
瀏覽"簡介"
地點包括 "台灣" 的 Blogger。
http://www.blogger.com/profile-find.g?t=l&loc0=CN
瀏覽簡介
地點包括 中國 的 Blogger。
http://www.blogger.com/next-blog?navBar=true&blogID=4996114541351894451
http://www.ytower.com.tw/ 全球華文最強食譜服務網站 仍吃素
我是 不是我 的我
# 留言人: 趙崇亨只當台灣人
# 主題:必定只想在台灣剃度出家
# 留言時間:2010-04-08 16:19:01
# 留言內容:阿彌陀佛 無相佈施
不要吃五辛(葷菜,在古代宗教指的是一些食用後會影響性情、慾望的植
物,主要有五種葷菜,合稱五葷,佛家與道家所指有異。
近代則訛稱含有動物性成分的餐飲食物為「葷菜」,事實上這在古代是稱
之為腥。所謂「葷腥」即這兩類的合稱。 葷菜
維基百科,自由的百科全書
(重定向自五辛) 佛家五葷
在佛家另稱為五辛,五種辛味之菜。根據《楞嚴經》記載,佛家五葷為大
蒜、小蒜、興渠、慈蔥、茖蔥;五葷生啖增恚,使人易怒;熟食發淫,令
人多慾。[1]
《本草備要》註解云:「慈蔥,冬蔥也;茖蔥,山蔥也;興渠,西域菜,云
即中國之荽。」
興渠另說為洋蔥。) 肉 蛋 奶?!
念楞嚴經 *∞窮盡相關 消去無關 證據 時效 念阿彌陀佛往生西方極樂世界
我想製造自己的行為反作用力
不婚 不生子女 生生世世不當老師
log 二0.3010 三0.47710.48 五0.6990 七0.8451 .85
root 二1.414 1.41 三1.732 1.73五 2.236 2.24七 2.646
=>十3.16 π∈Q' 一點八1.34
個人 和公共不一樣
Post a Comment