I. Background
Brother recently made a management background operations recorded a small drop DB demand, the implementation process need to get the user's login information operations, but queries that require login information from another company AD RPC service system by the way, in order to both determine the user's reach login status, but also be able to use the login information in the CRUD. Thinking I realize that, in the CRUD request arrives before the Controller layer, use interceptors to capture the request, calling AD service verification request carries the Cookie information is valid, and get to "account, UID, other basic information," the user, in order to be able to service layer to obtain the basic information, but not to call again call service [AD] is time-consuming process, I decided to save the user state information to the ThreadLocal, so in the same way as a thread have access to. ,
Implement no problem, but the younger brother suddenly thought, after the thread is finished, the thread information corresponding to the user mode you will continue to exist, it will be automatically recovered JVM, if not immediately recall, a lot of CRUD will not affect the server's memory . And in order to browse before a rough go over the "in-depth understanding of JVM virtual machine" in practice, it led to this question. That "ThreaLoacl memory structures in-depth analysis" + "ThreadLocal garbage collection mechanism is what made"
Two, ThreadLocal principle
2.1ThreadLocal Overview
2.2ThreadLocal structure
2.3ThreadLocal recovery strategy
By reading the source code, we can clearly understand its garbage collection mode. Here's a look at the source code documentation doc
Thread AN Implicit Reference holds each to ITS A Copy of Thread-local
* Long variable AS AS IS Alive The Thread and the ThreadLocal The @code {}
* Accessible IS instance; Thread A goes After Away, All of copies of ITS
* Thread-local Subject to Garbage Collection are instances (the unless OTHER
* the references to THESE copies exist).
is not very clear, "as long as there is this thread, and ThreadLocal instance is accessible, then the thread holds an implicit reference to the thread-local, but when this thread disappeared (ie finished), it holds thread_local backup will enter garbage collection (unless there are other references to this backup), "
of course, if just stop there, then there is no need to write this the article. Why it can be backed up with the disappearance of it for garbage collection thread to continue under the following analysis.
(1) references virtual
https://www.cnblogs.com/mfrank/p/9837070.html
https://www.jianshu.com/p/825cca41d962
Soft references, weak references, phantom references - their features and application scenarios
(2) Soft Reference
(3) weak reference
(4) strong references
Third, with regard to the type of reference
Fourth, on the garbage collection mechanism
https://mahl1990.iteye.com/blog/2347932 memory leaks Comments