ThreadLocal
GC 之后 key 是否为 null?
不一定。
(1)当使用new ThreadLocal<>().set(s);
定义threadlocal时,没有在栈中声明一个变量指向他,那他就是只被弱引用。在gc后,那这个threadlocal就会被回收,key为null,value还一直在,就会造成内存泄漏,所以注意在使用完threadlocal后一定要调用remove方法,避免因为key为null造成内存泄漏。
(2)当使用ThreadLocal<object> threadLocal = new ThreadLocal<>();
方式定义时,相当于栈中存在一个变量threadLocal指向这个对象,形成强引用,即使在entry中,作为key是弱引用,但是在栈中一直有一个名为“threadLocal”的变量在指向他,存在强引用,所以这种情况下不会导致key为空。但是只要该变量所在的方法执行完之后,threadLocal变量消失,只剩一个弱引用,那么key也还是会被清理变成null。
为什么key使用弱引用?
如果使用强引用,当ThreadLocal
对象的引用(强引用)被回收了,ThreadLocalMap
本身依然还持有ThreadLocal
的强引用,如果没有手动删除这个key ,则ThreadLocal
不会被回收,所以只要当前线程不消亡,ThreadLocalMap
引用的那些对象就不会被回收, 可以认为这导致Entry
内存泄漏。
ThreadLocalMap扩容机制
在ThreadLocalMap.set()
方法的最后,如果执行完启发式清理工作后,未清理到任何数据,且当前散列数组中Entry
的数量已经达到了列表的扩容阈值(len*2/3)
,就开始执行rehash()
逻辑:这里首先是会进行探测式清理工作,从table
的起始位置往后清理,table
中可能有一些key
为null
的Entry
数据被清理掉,此时通过判断size >= threshold * 3/4
来决定是否扩容。
接着看看具体的resize()
方法,为了方便演示,扩容后的tab
的大小为oldLen * 2
,重新计算hash
位置,然后放到新的tab
数组中,如果出现hash
冲突则往后寻找最近的entry
为null
的槽位,遍历完成之后,oldTab
中所有的entry
数据都已经放入到新的tab
中了。
使用ThreadLocal
的时候,在异步场景下无法给子线程共享父线程中创建的线程副本数据
为了解决这个问题,JDK 中还有一个InheritableThreadLocal
类,实现原理是子线程是通过在父线程中通过调用new Thread()
方法来创建子线程,Thread#init
方法在Thread
的构造方法中被调用。在init
方法中拷贝父线程数据到子线程中。
ThreadLocal
项目中使用实战
- 储存用户token
- traceId链路调用
ThreadPoolExecutor
ThreadPoolExecutor饱和策略定义
如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时,ThreadPoolTaskExecutor
定义一些策略:
ThreadPoolExecutor.AbortPolicy
:(默认情况)抛出RejectedExecutionException
来拒绝新任务的处理。ThreadPoolExecutor.CallerRunsPolicy
:调用执行自己的线程运行任务,也就是直接在调用execute
方法的线程中运行(run
)被拒绝的任务,如果执行程序已关闭,则会丢弃该任务。因此这种策略会降低对于新任务提交速度,影响程序的整体性能。如果您的应用程序可以承受此延迟并且你要求任何一个任务请求都要被执行的话,你可以选择这个策略。ThreadPoolExecutor.DiscardPolicy
:不处理新任务,直接丢弃掉。ThreadPoolExecutor.DiscardOldestPolicy
:此策略将丢弃最早的未处理的任务请求。
线程池创建两种方式
方式一:通过ThreadPoolExecutor
构造函数来创建(推荐)。
方式二:通过 Executor
框架的工具类 Executors
来创建。
FixedThreadPool
:该方法返回一个固定线程数量的线程池。线程池中的线程数量始终不变。当有一个新的任务提交时,线程池中若有空闲线程,则立即执行。若没有,则新的任务会被暂存在一个任务队列中,待有线程空闲时,便处理在任务队列中的任务。SingleThreadExecutor
: 该方法返回一个只有一个线程的线程池。若多余一个任务被提交到该线程池,任务会被保存在一个任务队列中,待线程空闲,按先入先出的顺序执行队列中的任务。CachedThreadPool
: 该方法返回一个可根据实际情况调整线程数量的线程池。线程池的线程数量不确定,但若有空闲线程可以复用,则会优先使用可复用的线程。若所有线程均在工作,又有新的任务提交,则会创建新的线程处理任务。所有线程在当前任务执行完毕后,将返回线程池进行复用。ScheduledThreadPool
:该返回一个用来在给定的延迟后运行任务或者定期执行任务的线程池。
方式二不推荐,因为:
FixedThreadPool
和SingleThreadExecutor
:使用的是无界的LinkedBlockingQueue
,任务队列最大长度为Integer.MAX_VALUE
,可能堆积大量的请求,从而导致 OOM。
CachedThreadPool
:使用的是同步队列SynchronousQueue
,没有容量,当没有空闲线程时,就立即申请线程, 允许创建的线程数量为Integer.MAX_VALUE
,可能会创建大量线程,从而导致 OOM。
ScheduledThreadPool
和SingleThreadScheduledExecutor
: 使用的无界的延迟阻塞队列DelayedWorkQueue
, 添加元素满了之后会自动扩容原来容量的 1/2,即永远不会阻塞,任务队列最大长度为Integer.MAX_VALUE
,可能堆积大量的请求,从而导致 OOM。
DelayedWorkQueue
的内部元素并不是按照放入的时间排序,而是会按照延迟的时间长短对任务进行排序,内部采用的是“堆”的数据结构。
线程池原理分析
Runnable vs Callable
Runnable
接口不会返回结果或抛出检查异常,但是 **Callable
接口 **可以。
工具类 Executors
可以实现将 Runnable
对象转换成 Callable
对象,属于是转换器模式。
submit vs execute区别
execute()
方法用于提交不需要返回值的任务,所以无法判断任务是否被线程池执行成功与否;
submit()
方法用于提交需要返回值的任务。线程池会返回一个 Future
类型的FutureTask对象,通过 Future
的 get()
方法来获取返回值,get()
方法会阻塞当前线程直到任务完成,而使用 get(long timeout,TimeUnit unit)
方法的话,如果在 timeout
时间内任务还没有执行完,就会抛出 java.util.concurrent.TimeoutException
。
shutdown() VS shutdownNow()
shutdown()
:关闭线程池,线程池的状态变为SHUTDOWN
。线程池不再接受新任务了,但是队列里的任务得执行完毕。shutdownNow()
:关闭线程池,线程的状态变为STOP
。线程池会终止当前正在运行的任务,并停止处理排队的任务并返回正在等待执行的 List。
isTerminated() VS isShutdown()
isShutDown
当调用shutdown()
方法后返回为 true。isTerminated
当调用shutdown()
方法后,并且所有提交的任务完成后返回为 true
ScheduledThreadPoolExecutor 和 Timer 对比
Timer
对系统时钟的变化敏感,ScheduledThreadPoolExecutor
不是;Timer
只有一个执行线程,因此长时间运行的任务可以延迟其他任务。ScheduledThreadPoolExecutor
可以配置任意数量的线程。 此外,如果你想(通过提供ThreadFactory
),你可以完全控制创建的线程;
。ScheduledThreadPoolExecutor
可以配置任意数量的线程。 此外,如果你想(通过提供ThreadFactory
),你可以完全控制创建的线程;- 在
TimerTask
中抛出的运行时异常会杀死一个线程,从而导致Timer
死机即计划任务将不再运行。ScheduledThreadExecutor
不仅捕获运行时异常,还允许您在需要时处理它们(通过重写afterExecute
方法ThreadPoolExecutor
)。抛出异常的任务将被取消,但其他任务将继续运行。