闭关修行中......
按照设计来说,ThreadLocal应该依附于Thread的存在而存在,每一个线程都可以有一份空间来存储,所以你说的第2点我非常赞同,至于第1点,我不太看得懂。如果按照你的设计,将map放在ThreadLocal,那么这个map得是static的(或者ThreadLocal单例中的成员变量),这样在设计上存在严重问题,这个map将非常难以管理:
ThreadLocal
Thread
map
static
1. 试想有没有线程安全问题? 2. 线程销毁后怎么处理,不做处理这个map将会越来越大?
设计都有一套方法,甚至有关哲学,得细细品味。
至少我能想到的一点就是:
减少互斥的代价
有一个场景: 为了提升DateFormat的性能, 一般会结合ThreadLocal.
有些设计有时候并不是单纯为了性能,要知道Java是最注重设计模式的,而单一职责是设计模式最重要的原则之一。反过来说,在ThreadLocal里直接实现一套Map岂不是比直接使用Map更快速度吗,但显然这么做有违单一职责,也使得维护的成本更高。
如果ThreadLoad直接使用Map<Thread, Object>为底层数据结构,当有大量的线程使用ThreadLocal时,首先Map访问的性能会下降,伴随着线程生命周期,底层的Map还需要频繁的添加删除entity,这就很容易造成性能瓶颈。
按照设计来说,
ThreadLocal
应该依附于Thread
的存在而存在,每一个线程都可以有一份空间来存储,所以你说的第2点我非常赞同,至于第1点,我不太看得懂。如果按照你的设计,将
map
放在ThreadLocal
,那么这个map
得是static
的(或者ThreadLocal
单例中的成员变量),这样在设计上存在严重问题,这个map
将非常难以管理:设计都有一套方法,甚至有关哲学,得细细品味。
至少我能想到的一点就是:
有一个场景: 为了提升DateFormat的性能, 一般会结合ThreadLocal.
有些设计有时候并不是单纯为了性能,要知道Java是最注重设计模式的,而单一职责是设计模式最重要的原则之一。
反过来说,在ThreadLocal里直接实现一套Map岂不是比直接使用Map更快速度吗,但显然这么做有违单一职责,也使得维护的成本更高。
如果ThreadLoad直接使用Map<Thread, Object>为底层数据结构,当有大量的线程使用ThreadLocal时,首先Map访问的性能会下降,伴随着线程生命周期,底层的Map还需要频繁的添加删除entity,这就很容易造成性能瓶颈。