基本功篇已经讲解了ThreadLocal的原理,大家制造的变量是足以被其余贰个线程访问并修改的

8.2 使用ThreadLocal不当大概会造成内存败露

基础篇已经讲解了ThreadLocal的法则,本节尊敬来上课下采取ThreadLocal会导致内存走漏的来头,并主讲使用ThreadLocal导致内存败露的案例。

ThreadLocal是2个关于创制线程局地变量的类。

8.2.1 为什么会油不过生内存走漏

基础篇大家讲到了ThreadLocal只是二个工具类,具体存放变量的是在线程的threadLocals变量里面,threadLocals是一个ThreadLocalMap类型的,

图片 1

image.png

如上图ThreadLocalMap内部是3个Entry数组,Entry继承自WeakReference,Entry内部的value用来存放通过ThreadLocal的set方法传递的值,那么ThreadLocal对象自作者存放到哪儿了吗?上面看看Entry的构造函数:

 Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
 }

public WeakReference(T referent) {
   super(referent);
}

Reference(T referent) {
   this(referent, null);
}

Reference(T referent, ReferenceQueue<? super T> queue) {

   this.referent = referent;
   this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
}

可见k被传送到了WeakReference的构造函数里面,相当于说ThreadLocalMap里面的key为ThreadLocal对象的弱引用,具体是referent变量引用了ThreadLocal对象,value为实际调用ThreadLocal的set方法传递的值。

当一个线程调用ThreadLocal的set方法设置变量时候,当前线程的ThreadLocalMap里面就会存放三个记下,这么些记录的key为ThreadLocal的引用,value则为设置的值。固然当前线程一向留存而从不调用ThreadLocal的remove方法,并且那时候其余地点照旧有对ThreadLocal的引用,则当前线程的ThreadLocalMap变量里面会设有ThreadLocal变量的引用和value对象的引用是不会被释放的,那就会招致内存走漏的。但是考虑如若那一个ThreadLocal变量没有了其他强重视,而目前线程还存在的意况下,由于线程的ThreadLocalMap里面的key是弱正视,则当前线程的ThreadLocalMap里面的ThreadLocal变量的弱引用会被在gc的时候回收,不过对应value仍然会促成内存败露,那时候ThreadLocalMap里面就会设有key为null可是value不为null的entry项。其实在ThreadLocal的set和get和remove方法里面有部分时机是会对这么些key为null的entry实行清理的,但是那么些清理不是必须暴发的,上面简单说下ThreadLocalMap的remove方法的清理进程:

private void remove(ThreadLocal<?> key) {

  //(1)计算当前ThreadLocal变量所在table数组位置,尝试使用快速定位方法
  Entry[] tab = table;
  int len = tab.length;
  int i = key.threadLocalHashCode & (len-1);
  //(2)这里使用循环是防止快速定位失效后,变量table数组
  for (Entry e = tab[i];
       e != null;
       e = tab[i = nextIndex(i, len)]) {
      //(3)找到
      if (e.get() == key) {
          //(4)找到则调用WeakReference的clear方法清除对ThreadLocal的弱引用
          e.clear();
          //(5)清理key为null的元素
          expungeStaleEntry(i);
          return;
      }
  }
}


 private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            //(6)去掉去value的引用
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            size--;

            Entry e;
            int i;
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();

                //(7)如果key为null,则去掉对value的引用。
                if (k == null) {
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    if (h != i) {
                        tab[i] = null;
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            return i;
        }
  • 手续(4)调用了Entry的clear方法,实际调用的是父类WeakReference的clear方法,功用是去掉对ThreadLocal的弱引用。
  • 手续(6)是去掉对value的引用,到此地当前线程里面的当下ThreadLocal对象的音讯被清理甘休了。
  • 代码(7)从当前成分的下标起始看table数组里面的别样因素是或不是有key为null的,有则清理。循环退出的基准是遭逢table里面有null的因素。所以那里通晓null成分后边的Entry里面key
    为null的要素不会被清理。

统计:ThreadLocalMap内部Entry中key使用的是对ThreadLocal对象的弱引用,那为防止内存走漏是三个升华,因为假若是强引用,那么即使其他地点没有对ThreadLocal对象的引用,ThreadLocalMap中的ThreadLocal对象依旧不会被回收,而一旦是弱引用则那时候ThreadLocal引用是会被回收掉的,即便对于的value如故不可以被回收,那时候ThreadLocalMap里面就会设有key为null可是value不为null的entry项,即使ThreadLocalMap提供了set,get,remove方法在局地空子下会对那么些Entry项进行清理,但是那是不及时的,也不是历次都会进行的,所以部分动静下依然会发出内存走漏,所以在利用落成后就是调用remove方法才是缓解内存走漏的王道。

普通状态下,我们创制的变量是可以被别的3个线程访问并修改的。而使用ThreadLocal制造的变量只可以被当下线程访问,其他线程则不或者访问和改动。

8.2.2 线程池中使用ThreadLocal导致的内存败露

上边先看线程池中采纳ThreadLocal的例证:

public class ThreadPoolTest {

    static class LocalVariable {
        private Long[] a = new Long[1024*1024];
    }

    // (1)
    final static ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES,
            new LinkedBlockingQueue<>());
    // (2)
    final static ThreadLocal<LocalVariable> localVariable = new ThreadLocal<LocalVariable>();

    public static void main(String[] args) throws InterruptedException {
        // (3)
        for (int i = 0; i < 50; ++i) {
            poolExecutor.execute(new Runnable() {
                public void run() {
                    // (4)
                    localVariable.set(new LocalVariable());
                    // (5)
                    System.out.println("use local varaible");
                    //localVariable.remove();

                }
            });

            Thread.sleep(1000);
        }
        // (6)
        System.out.println("pool execute over");
    }
  • 代码(1)创制了一个大旨线程数和最大线程数为5的线程池,这些保障了线程池里面随时都有两个线程在运转。
  • 代码(2)创设了一个ThreadLocal的变量,泛型参数为LocalVariable,LocalVariable内部是多少个Long数组。
  • 代码(3)向线程池里面放入肆拾陆个职分
  • 代码(4)设置当前线程的localVariable变量,也等于把new的LocalVariable变量放入当前线程的threadLocals变量。
  • 鉴于并未调用线程池的shutdown或然shutdownNow方法所以线程池里面的用户线程不会脱离,进而JVM进度也不会脱离。

运转当前代码,使用jconsole监控堆内存变化如下图:

图片 2

image.png

然后解开localVariable.remove()注释,然后在运行,观看堆内存变化如下:

图片 3

image.png

从运维结果一可见,当主线程处于休眠时候经过占用了大概77M内存,运维结果二则占据了大约25M内存,可见运转代码权且候内存发生了泄漏,上边分析下泄露的原故。

运转结果一的代码,在设置线程的localVariable变量后不曾调用localVariable.remove()
主意,导致线程池里面的五个线程的threadLocals变量里面的new LocalVariable()实例没有被保释,纵然线程池里面的职分执行落成了,不过线程池里面的四个线程会一向存在直到JVM退出。那里需求留意的是由于localVariable被声称了static,纵然线程的ThreadLocalMap里面是对localVariable的弱引用,localVariable也不会被回收。运行结果二的代码由于线程在安装localVariable变量后纵然调用了localVariable.remove()办法开展了清理,所以不会存在内存走漏。

计算:线程池里面安装了ThreadLocal变量一定要记得当时清理,因为线程池里面的为主线程是一贯留存的,假使不清理,那么线程池的主导线程的threadLocals变量向来会有着ThreadLocal变量。

ThreadLocal是什么为各样线程创造变量的副本的:
  首先,在各类线程Thread内部有3个ThreadLocal.ThreadLocalMap类型的分子变量threadLocals,那一个threadLocals就是用来存储实际的变量副本的,键值为眼下ThreadLocal变量,value为变量副本(即T类型的变量)。
  起头时,在Thread里面,threadLocals为空,当通过ThreadLocal变量调用get()方法照旧set()方法,就会对Thread类中的threadLocals举行开端化,并且以方今ThreadLocal变量为键值,以ThreadLocal要封存的副本变量为value,存到threadLocals。

8.2.3 Tomcat的Servlet中接纳ThreadLocal导致内存败露

率先看一个Servlet的代码如下:

public class HelloWorldExample extends HttpServlet {

    private static final long serialVersionUID = 1L;

    static class LocalVariable {
        private Long[] a = new Long[1024 * 1024 * 100];
    }

    //(1)
    final static ThreadLocal<LocalVariable> localVariable = new ThreadLocal<LocalVariable>();

    @Override
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException {
        //(2)
        localVariable.set(new LocalVariable());

        response.setContentType("text/html");
        PrintWriter out = response.getWriter();

        out.println("<html>");
        out.println("<head>");

        out.println("<title>" + "title" + "</title>");
        out.println("</head>");
        out.println("<body bgcolor=\"white\">");
        //(3)
        out.println(this.toString());
        //(4)
        out.println(Thread.currentThread().toString());

        out.println("</body>");
        out.println("</html>");
    }
}
  • 代码(1)创立1个localVariable对象,
  • 代码(2)在servlet的doGet方法内设置localVariable值
  • 代码(3)打印当前servlet的实例
  • 代码(4)打印当前线程

修改tomcat的conf下sever.xml配置如下:

    <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" 
        maxThreads="10" minSpareThreads="5"/>

    <Connector executor="tomcatThreadPool" port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

此间设置了tomcat的处理线程池最大线程为1二个,最小线程为5个,那么这一个线程池是为啥用的那?那里回想下汤姆cat的器皿结构,如下图:

图片 4

image.png

汤姆cat中Connector组件负责接受并处理请求,其中Socket acceptor thread
负责接受用户的走访请求,然后把接受到的请求提交Worker threads
pool线程池进行实际处理,后者就是大家在server.xml里面配备的线程池。Worker
threads
pool里面的线程则承担把具体请求分发到实际的应用的servlet上拓展拍卖。

有了上述知识,下边运行tomcat访问该servlet数十遍,会发觉有恐怕输出上边结果

HelloWorldExample@2a10b2d2 Thread[catalina-exec-5,5,main]
HelloWorldExample@2a10b2d2 Thread[catalina-exec-1,5,main]
HelloWorldExample@2a10b2d2 Thread[catalina-exec-4,5,main]

里面前半部分是打印的servlet实例,那里都同样表达数次拜访的都以1个servlet实例,后半有的中catalina-exec-5,catalina-exec-1,catalina-exec-4,表达使用了connector中线程池里面的线程5,线程1,线程4来实施serlvet的。
假设在访问该servlet的还要打开了jconsole观察堆内存会发现内存会飙升,究其原因是因为做事线程调用servlet的doGet方法时候,工作线程的threadLocals变量里面被添加了new
LocalVariable()实例,不过并未被remove,其余数拾肆回拜访该servlet只怕用的不是工作线程池里面的同三个线程,那会招致工作线程池里面几个线程都会存在内存走漏。

更不佳的还在前面,上边的代码在tomcat6.0的一世,应用reload操作后会导致加载该行使的webappClassLoader释放不了,这是因为servlet的doGet方法里面创制new
LocalVariable()的时候使用的是webappclassloader,所以LocalVariable.class里面全体webappclassloader的引用,由于LocalVariable的实例没有被放走,所以LocalVariable.class对象也未尝没释放,所以
webappclassloader也尚无被释放,那么webappclassloader加载的拥有类也从没被假释。那是因为运用reload的时候connector组件里面的工作线程池里面的线程还是一贯留存的,并且线程里面的threadLocals变量并不曾被清理。而在tomcat7.0里面这些难题被修复了,应用在reload时候会清理工作线程池中线程的threadLocals变量,tomcat7.0里面reload后会有如下提醒:

十二月 31, 2017 5:44:24 下午 org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks
严重: The web application [/examples] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@63a3e00b]) and a value of type [HelloWorldExample.LocalVariable] (value [HelloWorldExample$LocalVariable@4fd7564b]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

图片 5

8.2.4 总结

Java提供的ThreadLocal给大家编程提供了福利,不过只要使用不当也会给我们带来沉重的磨难,编码时候要养成卓越的习惯,线程中运用完ThreadLocal变量后,要记得当时remove掉。

迎接关怀微信公众号 ‘技术原始积累’

以下代码显示了什么样成立2个ThreadLocal变量:

    private ThreadLocal<String> myThreadLocal = new ThreadLocal<>();
    @Test
    public void testx() {
        Thread t = new Thread() {
            @Override
            public void run() {
                myThreadLocal.set("icecrea");
                System.out.println(myThreadLocal.get());
            }
        };
        t.start();
        Thread t2 = new Thread() {
            @Override
            public void run() {
                System.out.println("t2------"+myThreadLocal.get());
            }
        };
        t2.start();
    }

作者们可以看看,通过那段代码实例化了一个ThreadLocal对象。我们只必要实例化对象一遍,并且也不必要知道它是被哪些线程实例化。就算具有的线程都能访问到那几个ThreadLocal实例,不过各样线程却只得访问到自个儿通过调用ThreadLocal的set()方法设置的值。即使是四个例外的线程在同1个ThreadLocal对象上设置了不相同的值,他们一如既往不或然访问到对方的值。
自然,大家也得以复习方法设置伊始值,那样地方的t2线程就会打印出开端值。

    private ThreadLocal<String> myThreadLocal = new ThreadLocal<String>(){
        @Override
        public String initialValue(){
            return "This is the initial value";
        }
    };

源码解读:
ThreadLocal的set方法,分为上边三步:

  • 率先拿到当前线程
  • 选择当前线程作为句柄获取二个ThreadLocalMap的靶子
  • 一旦上述ThreadLocalMap对象不为空,则设置值,否则成立那一个ThreadLocalMap对象并设置值

只顾:
那里set方法里,第②行取得的是当前线程里的threadlocals那个变量副本,第伍行传入了this,即threadlocal对象作为key,之后流入到线程的变量副本里。通过ThreadLocal.set()将这几个新创立的目的的引用保存到各线程的祥和的1个map中,每种线程都有那样三个map,执行ThreadLocal.get()时,各线程从友好的map中取出放进去的靶子,因而取出来的是各自自个儿线程中的对象,ThreadLocal实例是作为map的key来使用的。

为何threadLocals的品种ThreadLocalMap的键值为ThreadLocal对象?因为各种线程中可有多个threadLocal变量。

public class ThreadLocal<T> {
     ...
    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }

        ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
            table = new Entry[INITIAL_CAPACITY];
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
            table[i] = new Entry(firstKey, firstValue);
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }
  ...
}

同理,ThreadLocal的get方法,
收获当前线程,获取线程持有的ThreadLocalMap,获取值

    public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        return setInitialValue();
    }

在Thread类中,持有ThreadLocal.ThreadLocalMap的引用变量。实际上ThreadLocal的值是放入了近年来线程的三个ThreadLocalMap实例中,所以只幸亏本线程中走访,其余线程无法访问。

public class Thread implements Runnable {
    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

InheritableThreadLocal

是还是不是说ThreadLocal的值只好被1个线程访问呢?
运用InheritableThreadLocal能够兑现三个线程访问ThreadLocal的值。
原因是Thread类的Init方法(此处只列相关代码),

    private void init(ThreadGroup g, Runnable target, String name,
                      long stackSize, AccessControlContext acc,
                      boolean inheritThreadLocals) {
       ...
        if (inheritThreadLocals && parent.inheritableThreadLocals != null)
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
      ...
    }

可以看出,使用InheritableThreadLocal可以将有些线程的ThreadLocal值在其子线程创立时传递过去。

    static ThreadLocalMap createInheritedMap(ThreadLocalMap parentMap) {
        return new ThreadLocalMap(parentMap);
    }

     private ThreadLocalMap(ThreadLocalMap parentMap) {
            Entry[] parentTable = parentMap.table;
            int len = parentTable.length;
            setThreshold(len);
            table = new Entry[len];

            for (int j = 0; j < len; j++) {
                Entry e = parentTable[j];
                if (e != null) {
                    @SuppressWarnings("unchecked")
                    ThreadLocal<Object> key = (ThreadLocal<Object>) e.get();
                    if (key != null) {
                        Object value = key.childValue(e.value);
                        Entry c = new Entry(key, value);
                        int h = key.threadLocalHashCode & (len - 1);
                        while (table[h] != null)
                            h = nextIndex(h, len);
                        table[h] = c;
                        size++;
                    }
                }
            }
        }

下边代码子线程可以访问到父线程中InheritableThreadLocal的值。打印icecrea。(此处假诺用threadLocal实例再次来到的则是Null)

    @Test
    public void testInheritableThreadLocal() {
        final ThreadLocal threadLocal = new InheritableThreadLocal();
        threadLocal.set("icecrea");
        Thread t = new Thread() {
            @Override
            public void run() {
                super.run();
                System.out.println(threadLocal.get());
            }
        };

        t.start();
    }

ThreadLocalMap

图片 6

ThreadLocalMap有静态内部类Entry,是ThreadLocal的弱引用项目,持有Object类型的引用。持有Entry[]数组。

 /**
         * The entries in this hash map extend WeakReference, using
         * its main ref field as the key (which is always a
         * ThreadLocal object).  Note that null keys (i.e. entry.get()
         * == null) mean that the key is no longer referenced, so the
         * entry can be expunged from table.  Such entries are referred to
         * as "stale entries" in the code that follows.
         */

  static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }

   private Entry[] table;

构造方法如下。通过ThreaLocal和Object值来组织ThreadLocalMap,再回想上面的ThreadLocal的get方法,就是经过得到ThreadLocalMap,在调用它的getEntry方法,总括HASH值,定位Entry在table数组中的地方重临,获取value的值。

   ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
            table = new Entry[INITIAL_CAPACITY];
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
            table[i] = new Entry(firstKey, firstValue);
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }

        private Entry getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
                return getEntryAfterMiss(key, i, e);
        }

ThreadLocal会内存走漏么

内存泄漏的概念:对象已经远非被应用程序使用,可是垃圾回收器不可以移除它们,因为还在被引述着。

threadlocal里面使用了二个存在弱引用的map,当释放掉threadlocal的强引用将来,map里面的value却绝非被回收.而那块value永远不会被访问到了.
所以存在着内存走漏. 最好的做法是将调用threadlocal的remove方法.

图片 7

  逐个thread中都留存1个map, map的序列是ThreadLocal.ThreadLocalMap.
Map中的key为1个threadlocal实例.
这一个Map的确使用了弱引用,然则弱引用只是针对性key.
每种key都弱引用指向threadlocal.
当把threadlocal实例置为null未来,没有其余强引用指向threadlocal实例,所以threadlocal将会被gc回收.
不过,大家的value却不能回收,因为存在一条从current
thread连接过来的强引用. 唯有当前thread截止以往, current
thread就不会存在栈中,强引用断开, Current Thread, Map,
value将整体被GC回收.
  所以得出壹个结论就是即使那几个线程对象被gc回收,就不会冒出内存败露,但在threadLocal设为null和线程停止那段时光不会被回收的,就生出了我们以为的内存泄露。最丰富的是线程对象不被回收的图景,那就暴发了确实意义上的内存泄露。比如使用线程池的时候,线程停止是不会销毁的,会重新使用的。就只怕出现内存败露。

Java为了最小化裁减内存走漏的只怕和潜移默化,在ThreadLocal的get,set的时候都会去掉线程Map里全体key为null的value。所以最怕的情形就是,threadLocal对象设null了,早先爆发“内存败露”,然后使用线程池,这几个线程截至,线程放回线程池中不销毁,那么些线程一直不被使用,可能分配使用了又不再调用get,set方法,那么那个里面就会发生真正的内存走漏。

对此单身的java文件,要如下设置(参数不只怕放在Test前面)
java -Xms64m -Xmx256m Test

图片 8

Linux tomcat下:
在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh添加:JAVA_OPTS=’-Xms512m
-Xmx1024m’要加“m”表达是MB,否则就是KB了,在起步tomcat时会报内存不足。

起来堆大小-Xms64m
最大堆大小 -Xmx256m

不掌握springboot下怎样设置tomcat?试了上边那一个和接近的都没得逞
mvn spring-boot:run -DXms=64m -DXmx=256m
自小编的搞定方案是:mvn package, 然后java -jar -Xms64m -Xmx256m xxx.war
那样设置成功
测试代码如下:

    private ThreadLocal<List<String>> buffer=new ThreadLocal<>();
    @RequestMapping("threadLocal")
    @ResponseBody
    public String threadLocal(){
        List<String> list= Lists.newArrayList();
        for(int i=0;i<1024000;i++){
            list.add(String.valueOf(i));
        }
        buffer.set(list);
        return "success";
    }

报错消息如下

Exception in thread "http-nio-8080-exec-4" java.lang.OutOfMemoryError: GC overhead limit exceeded
        at javax.management.ObjectName.quote(ObjectName.java:1832)
        at org.apache.coyote.AbstractProtocol.getName(AbstractProtocol.java:385)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.register(AbstractProtocol.java:1087)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:857)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
        at java.lang.Thread.run(Thread.java:748)

旁观发现,value大内存并不曾回收

图片 9

缓解方案:添加
buffer.remove();方法手动回收Entry,消除了value不或者回收的难题。

  /**
         * Remove the entry for key.
         */
        private void remove(ThreadLocal<?> key) {
            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                if (e.get() == key) {
                    e.clear();
                    expungeStaleEntry(i);
                    return;
                }
            }
        }

采纳场景

焚薮而田 数据库连接、Session管理难点
数据库连接假设用常规方式,二十四线程访问要加锁,要相互等待,降低成效。可以运用threadlocal,线程不用相互等待,且他们之间向来不关系。但扩充了内存开销。

private static ThreadLocal<Connection> connectionHolder= new ThreadLocal<Connection>() {
  public Connection initialValue() {
      return DriverManager.getConnection(DB_URL);
  }
};

public static Connection getConnection() {
  return connectionHolder.get();
}

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;
}

参考小说:
https://www.cnblogs.com/dolphin0520/p/3920407.html
https://www.cnblogs.com/onlywujun/p/3524675.html

相关文章