详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcyt107java
首先,ThreadLocal 不是用来解决共享对象的多线程访问问题的,通常状况下,经过ThreadLocal.set() 到线程中的对象是该线程本身使用的对象,其余线程是不须要访问的,也访问不到的。各个线程中访问的是不一样的对象。
另外,说ThreadLocal使得各线程可以保持各自独立的一个对象,并非经过ThreadLocal.set()来实现的,而是经过每一个线程中的new 对象 的操做来建立的对象,每一个线程建立一个,不是什么对象的拷贝或副本。经过ThreadLocal.set()将这个新建立的对象的引用保存到各线程的本身的一个map中,每一个线程都有这样一个map,执行ThreadLocal.get()时,各线程从本身的map中取出放进去的对象,所以取出来的是各自本身线程中的对象,ThreadLocal实例是做为map的key来使用的。
若是ThreadLocal.set()进去的东西原本就是多个线程共享的同一个对象,那么多个线程的ThreadLocal.get()取得的仍是这个共享对象自己,仍是有并发访问问题。
下面来看一个hibernate中典型的ThreadLocal的应用: session
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
private
static
final
ThreadLocal threadSession =
new
ThreadLocal();
public
static
Session getSession()
throws
InfrastructureException {
Session s = (Session) threadSession.get();
try
{
if
(s ==
null
) {
s = getSessionFactory().openSession();
threadSession.set(s);
}
}
catch
(HibernateException ex) {
throw
new
InfrastructureException(ex);
}
return
s;
}
|
能够看到在getSession()方法中,首先判断当前线程中有没有放进去session,若是尚未,那么经过sessionFactory().openSession()来建立一个session,再将session set到线程中,实际是放到当前线程的ThreadLocalMap这个map中,这时,对于这个session的惟一引用就是当前线程中的那个ThreadLocalMap(下面会讲到),而threadSession做为这个值的key,要取得这个session能够经过threadSession.get()来获得,里面执行的操做实际是先取得当前线程中的ThreadLocalMap,而后将threadSession做为key将对应的值取出。这个session至关于线程的私有变量,而不是public的。
显然,其余线程中是取不到这个session的,他们也只能取到本身的ThreadLocalMap中的东西。要是session是多个线程共享使用的,那还不乱套了。
试想若是不用ThreadLocal怎么来实现呢?可能就要在action中建立session,而后把session一个个传到service和dao中,这可够麻烦的。或者能够本身定义一个静态的map,将当前thread做为key,建立的session做为值,put到map中,应该也行,这也是通常人的想法,但事实上,ThreadLocal的实现恰好相反,它是在每一个线程中有一个map,而将ThreadLocal实例做为key,这样每一个map中的项数不多,并且当线程销毁时相应的东西也一块儿销毁了,不知道除了这些还有什么其余的好处。
总之,ThreadLocal不是用来解决对象共享访问问题的,而主要是提供了保持对象的方法和避免参数传递的方便的对象访问方式。概括了两点:
1。每一个线程中都有一个本身的ThreadLocalMap类对象,能够将线程本身的对象保持到其中,各管各的,线程能够正确的访问到本身的对象。
2。将一个共用的ThreadLocal静态实例做为key,将不一样对象的引用保存到不一样线程的ThreadLocalMap中,而后在线程执行的各处经过这个静态ThreadLocal实例的get()方法取得本身线程保存的那个对象,避免了将这个对象做为参数传递的麻烦。
固然若是要把原本线程共享的对象经过ThreadLocal.set()放到线程中也能够,能够实现避免参数传递的访问方式,可是要注意get()到的是那同一个共享对象,并发访问问题要靠其余手段来解决。但通常来讲线程共享的对象经过设置为某类的静态变量就能够实现方便的访问了,彷佛不必放到线程中。
ThreadLocal的应用场合,我以为最适合的是按线程多实例(每一个线程对应一个实例)的对象的访问,而且这个对象不少地方都要用到。
下面来看看ThreadLocal的实现原理(jdk1.5源码) 多线程
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
public
class
ThreadLocal<T> {
/**
* ThreadLocals rely on per-thread hash maps attached to each thread
* (Thread.threadLocals and inheritableThreadLocals). The ThreadLocal
* objects act as keys, searched via threadLocalHashCode. This is a
* custom hash code (useful only within ThreadLocalMaps) that eliminates
* collisions in the common case where consecutively constructed
* ThreadLocals are used by the same threads, while remaining well-behaved
* in less common cases.
*/
private
final
int
threadLocalHashCode = nextHashCode();
/**
* The next hash code to be given out. Accessed only by like-named method.
*/
private
static
int
nextHashCode =
0
;
/**
* The difference between successively generated hash codes - turns
* implicit sequential thread-local IDs into near-optimally spread
* multiplicative hash values for power-of-two-sized tables.
*/
private
static
final
int
HASH_INCREMENT =
0x61c88647
;
/**
* Compute the next hash code. The static synchronization used here
* should not be a performance bottleneck. When ThreadLocals are
* generated in different threads at a fast enough rate to regularly
* contend on this lock, memory contention is by far a more serious
* problem than lock contention.
*/
private
static
synchronized
int
nextHashCode() {
int
h = nextHashCode;
nextHashCode = h + HASH_INCREMENT;
return
h;
}
/**
* Creates a thread local variable.
*/
public
ThreadLocal() {
}
/**
* Returns the value in the current thread's copy of this thread-local
* variable. Creates and initializes the copy if this is the first time
* the thread has called this method.
*
* @return the current thread's value of this thread-local
*/
public
T get() {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if
(map !=
null
)
return
(T)map.get(
this
);
// Maps are constructed lazily. if the map for this thread
// doesn't exist, create it, with this ThreadLocal and its
// initial value as its only entry.
T value = initialValue();
createMap(t, value);
return
value;
}
/**
* Sets the current thread's copy of this thread-local variable
* to the specified value. Many applications will have no need for
* this functionality, relying solely on the {@link #initialValue}
* method to set the values of thread-locals.
*
* @param value the value to be stored in the current threads' copy of
* this thread-local.
*/
public
void
set(T value) {
Thread t = Thread.currentThread();
ThreadLocalMap map = getMap(t);
if
(map !=
null
)
map.set(
this
, value);
else
createMap(t, value);
}
/**
* Get the map associated with a ThreadLocal. Overridden in
* InheritableThreadLocal.
*
* @param t the current thread
* @return the map
*/
ThreadLocalMap getMap(Thread t) {
return
t.threadLocals;
}
/**
* Create the map associated with a ThreadLocal. Overridden in
* InheritableThreadLocal.
*
* @param t the current thread
* @param firstValue value for the initial entry of the map
* @param map the map to store.
*/
void
createMap(Thread t, T firstValue) {
t.threadLocals =
new
ThreadLocalMap(
this
, firstValue);
}
.......
/**
* ThreadLocalMap is a customized hash map suitable only for
* maintaining thread local values. No operations are exported
* outside of the ThreadLocal class. The class is package private to
* allow declaration of fields in class Thread. To help deal with
* very large and long-lived usages, the hash table entries use
* WeakReferences for keys. However, since reference queues are not
* used, stale entries are guaranteed to be removed only when
* the table starts running out of space.
*/
static
class
ThreadLocalMap {
........
}
}
|
能够看到ThreadLocal类中的变量只有这3个int型: 并发
1
2
3
|
private
final
int
threadLocalHashCode = nextHashCode();
private
static
int
nextHashCode =
0
;
private
static
final
int
HASH_INCREMENT =
0x61c88647
;
|
而做为ThreadLocal实例的变量只有 threadLocalHashCode 这一个,nextHashCode 和HASH_INCREMENT 是ThreadLocal类的静态变量,实际上HASH_INCREMENT是一个常量,表示了连续分配的两个ThreadLocal实例的threadLocalHashCode值的增量,而nextHashCode 的表示了即将分配的下一个ThreadLocal实例的threadLocalHashCode 的值。
能够来看一下建立一个ThreadLocal实例即new ThreadLocal()时作了哪些操做,从上面看到构造函数ThreadLocal()里什么操做都没有,惟一的操做是这句: less
1
|
private
final
int
threadLocalHashCode = nextHashCode();
|
那么nextHashCode()作了什么呢: 函数
1
2
3
4
5
|
private
static
synchronized
int
nextHashCode() {
int
h = nextHashCode;
nextHashCode = h + HASH_INCREMENT;
return
h;
}
|
就是将ThreadLocal类的下一个hashCode值即nextHashCode的值赋给实例的threadLocalHashCode,而后nextHashCode的值增长HASH_INCREMENT这个值。
所以ThreadLocal实例的变量只有这个threadLocalHashCode,并且是final的,用来区分不一样的ThreadLocal实例,ThreadLocal类主要是做为工具类来使用,那么ThreadLocal.set()进去的对象是放在哪儿的呢?
看一下上面的set()方法,两句合并一下成为 ui
1
|
ThreadLocalMap map = Thread.currentThread().threadLocals;
|
这个ThreadLocalMap 类是ThreadLocal中定义的内部类,可是它的实例却用在Thread类中:
1
2
3
4
5
6
7
8
|
public
class
Thread
implements
Runnable {
......
/* ThreadLocal values pertaining to this thread. This map is maintained
* by the ThreadLocal class. */
ThreadLocal.ThreadLocalMap threadLocals =
null
;
......
}
|
再看这句:
1
2
|
if
(map !=
null
)
map.set(
this
, value);
|
也就是将该ThreadLocal实例做为key,要保持的对象做为值,设置到当前线程的ThreadLocalMap 中,get()方法一样你们看了代码也就明白了,ThreadLocalMap 类的代码太多了,我就不帖了,本身去看源码吧。 写了这么多,也不知讲明白了没有,有什么不当的地方还请你们指出来。