jvm 优化篇-（5）-YongGC 回收WeakRefere
2019-12-06 本文已影响0人
tianlang136520
死神---浦原喜助
引用分类：
-
强引用（StrongReference）：强引用使用最普遍的引用，eg：
new Object()。 -
软引用（SoftReference）：软引用可用来实现内存敏感的高速缓存。一般用于系统内部缓存。
eg：一个对象只具有软引用，则内存空间足够，垃圾回收器♻️就不会回收它；如果内存空间不足了（FullGC），就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。 -
弱引用（WeakReference）：弱引用与软引用的区别在于：只具有弱引用的对象拥有
更短暂的生命周期。
eg：垃圾回收器♻️一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。（YongGC） -
虚引用（PhantomReference）：
❌后补❌
Java4种引用的级别由高到低依次为：
强引用 > 软引用 > 弱引用 > 虚引用
Java4中引用在垃圾回收中区别：
| 引用类型 | 回收♻️时间 | 用途 | 生存周期 |
|---|---|---|---|
| 强引用(StrongReference) | -- | 正常使用 | JVM停止⏹ |
| 软引用(WeakReference) | FullGC（❌cms-oldgc❌） | 系统内部缓存 | OOM前 |
| 弱引用(WeakReference) | YongGC | 对象缓存 | YongGC发生前 |
| 虚引用(PhantomReference) | -- | -- | -- |
今天重点讨论--->WeakReference
第一个问题：如何证明WeakReference在YongGC被回收♻️？
启动参数：
-Xmx50M -Xms50M -Xmn10M -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=90 -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime
-XX:+PrintReferenceGC -XX:+PrintTenuringDistribution
public static void main(String[] args) throws InterruptedException {
WeakReference<User> weakReference = new WeakReference<User>(new User("xiali", "123", "男", 18));
System.out.println("beforeGC:" + weakReference.get());
// 触发yonggc
allactionMemory();
// 防止yonggc耗时过长，先睡5s
TimeUnit.SECONDS.sleep(5);
System.out.println("afterGC:" + weakReference.get());
}
public static void allactionMemory(){
int size =1024*1024*12;
int len =size/(10*1024);
List<byte[]> list = new ArrayList<byte[]>();
for (int i =0;i<len;i++) {
try {
byte[] bytes = new byte[10*1024];
list.add(bytes);
} catch (Exception e) {
e.printStackTrace();
} finally {
}
}
}
static class User {
private String userName;
private String password;
private String sex;
private int age;
public User(String userName, String password, String sex, int age) {
this.userName = userName;
this.password = password;
this.sex = sex;
this.age = age;
}
@Override
public String toString() {
return "User{" +
"userName='" + userName + '\'' +
", password='" + password + '\'' +
", sex='" + sex + '\'' +
", age=" + age +
'}';
}
}
运行结果：
beforeGC:User{userName='xiali', password='123', sex='男', age=18}
{Heap before GC invocations=0 (full 0):
par new generation total 9216K, used 8192K [0x00000007bce00000, 0x00000007bd800000, 0x00000007bd800000)
eden space 8192K, 100% used [0x00000007bce00000, 0x00000007bd600000, 0x00000007bd600000)
from space 1024K, 0% used [0x00000007bd600000, 0x00000007bd600000, 0x00000007bd700000)
to space 1024K, 0% used [0x00000007bd700000, 0x00000007bd700000, 0x00000007bd800000)
concurrent mark-sweep generation total 40960K, used 0K [0x00000007bd800000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3198K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 354K, capacity 388K, committed 512K, reserved 1048576K
2019-11-30T23:05:49.532-0800: [GC (Allocation Failure) 2019-11-30T23:05:49.532-0800: [ParNew2019-11-30T23:05:49.541-0800: [SoftReference, 0 refs, 0.0000247 secs]2019-11-30T23:05:49.541-0800: [WeakReference, 8 refs, 0.0000108 secs]2019-11-30T23:05:49.541-0800: [FinalReference, 0 refs, 0.0000083 secs]2019-11-30T23:05:49.541-0800: [PhantomReference, 0 refs, 0 refs, 0.0000104 secs]2019-11-30T23:05:49.541-0800: [JNI Weak Reference, 0.0000098 secs]
Desired survivor size 524288 bytes, new threshold 1 (max 6)
- age 1: 1039264 bytes, 1039264 total
: 8192K->1024K(9216K), 0.0086417 secs] 8192K->6662K(50176K), 0.0086800 secs] [Times: user=0.01 sys=0.01, real=0.01 secs]
Heap after GC invocations=1 (full 0):
par new generation total 9216K, used 1024K [0x00000007bce00000, 0x00000007bd800000, 0x00000007bd800000)
eden space 8192K, 0% used [0x00000007bce00000, 0x00000007bce00000, 0x00000007bd600000)
from space 1024K, 100% used [0x00000007bd700000, 0x00000007bd800000, 0x00000007bd800000)
to space 1024K, 0% used [0x00000007bd600000, 0x00000007bd600000, 0x00000007bd700000)
concurrent mark-sweep generation total 40960K, used 5638K [0x00000007bd800000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3198K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 354K, capacity 388K, committed 512K, reserved 1048576K
}
2019-11-30T23:05:49.541-0800: Total time for which application threads were stopped: 0.0088985 seconds, Stopping threads took: 0.0000389 seconds
2019-11-30T23:05:50.544-0800: Total time for which application threads were stopped: 0.0000546 seconds, Stopping threads took: 0.0000167 seconds
2019-11-30T23:05:53.560-0800: Total time for which application threads were stopped: 0.0001106 seconds, Stopping threads took: 0.0000233 seconds
afterGC:null
Heap
par new generation total 9216K, used 7756K [0x00000007bce00000, 0x00000007bd800000, 0x00000007bd800000)
eden space 8192K, 82% used [0x00000007bce00000, 0x00000007bd493310, 0x00000007bd600000)
from space 1024K, 100% used [0x00000007bd700000, 0x00000007bd800000, 0x00000007bd800000)
to space 1024K, 0% used [0x00000007bd600000, 0x00000007bd600000, 0x00000007bd700000)
concurrent mark-sweep generation total 40960K, used 5638K [0x00000007bd800000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3352K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 371K, capacity 388K, committed 512K, reserved 1048576K
重点部分：
beforeGC:User{userName='xiali', password='123', sex='男', age=18}
afterGC:null
其他日志均为gclog。
第二个问题：ThreadLocalMap中Entry的Key是WeakReference，如果Yonggc时Key就会被回收♻️掉，应该会影响程序运行？但是现实中问题Yonggc又没有回收掉呢？为什么ThreadLocal被称为线程本地变量？
了解ThreadLocal，前提就要搞明白：Thread、ThreadLocalMap、ThreadLocal、Entry的关系是什么？
image.png
- 红色关系线表示：Entry是ThreadLocalMap的静态内部类，ThreadLocalMap是ThreadLocal的静态内部类。
- 蓝色关系线表示：Entry是继承弱引用类的，并且Key是采用弱引用修饰包装。
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
- Thread保有ThreadLocalMap引用。
总结：Thread持有--->ThreadLocalMap引用，其中：
ThreadLocalMap的Entry中(Key是ThreadLocal类型的弱引用) ，value是要保存的值。
Eg：创建四个ThreadLocal变量，其中前三个是Yonggc前操作的复制，第四个变量是Yonggc后进行操作赋值方便观察ThreadLocalMap中的变化。
启动参数：-Xmx50M -Xms50M -Xmn10M -XX:+UseConcMarkSweepGC -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=90 -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime
-XX:+PrintReferenceGC -XX:+PrintTenuringDistribution
public class TestYGCCleanTLKey {
static ThreadLocal<TestThreadLocalWeakReferenceMain.User> threadLocal = new ThreadLocal<>();
static ThreadLocal<TestThreadLocalWeakReferenceMain.User> threadLocal1 = new ThreadLocal<>();
static ThreadLocal<TestThreadLocalWeakReferenceMain.User> threadLocal2 = new ThreadLocal<>();
static ThreadLocal<TestThreadLocalWeakReferenceMain.User> threadLocal3 = new ThreadLocal<>();
public static void main(String[] args) {
threadLocal.set(new TestThreadLocalWeakReferenceMain.User("xiali", "123", "男", 18));
threadLocal1.set(new TestThreadLocalWeakReferenceMain.User("xiali", "111", "男", 18));
threadLocal2.set(new TestThreadLocalWeakReferenceMain.User("xiali", "222", "男", 18));
// 触发yonggc，尝试回收wkr
allactionMemory();
// debug观察Thread中的Entry情况：
threadLocal3.set(new TestThreadLocalWeakReferenceMain.User("kobe", "888", "男", 38));
System.out.println("结束");
System.out.println(threadLocal.get());
}
public static void allactionMemory(){
int size =1024*1024*12;
int len =size/(10*1024);
List<byte[]> list = new ArrayList<byte[]>();
for (int i =0;i<len;i++) {
try {
byte[] bytes = new byte[10*1024];
list.add(bytes);
} catch (Exception e) {
e.printStackTrace();
} finally {
}
}
}
}
debug过程截图
经过debug发现，
Yonggc是不能回收♻️ThreadLocalMap中Entry的弱引用Key的。
但是如果在执行Yonggc回收♻️前将前三个Threadlocal变量置为null呢？结果会怎样呢？？？
调整代码：
Yonggc执行前ThreadLocalMap中对象状态
Yonggc执行之后ThreadLocalMap中对象的状态
通过将变量置为null，经过Yonggc后ThreadLocalMap中Entry的Key被成功释放，但是Value依然存在！这也就是ThreadLocal常说的存在内存泄漏风险！！！
threadLocal = null;
threadLocal1 = null;
threadLocal2 = null;
到底是什么原因造成了这个显现的呢？
JVM运行时内存分配如下图：
JVM未回收♻️前内存分布
JVM进行Yonggc回收♻️后内存分布
结论：
- 1、从内存分配上可以看出ThreadLocalMap是Thread线程的本地变量，也就是说
ThreadLocalMap的生命周期与Thread同生同死。所以如果真的将ThreadLocal置为null，会发生内存泄漏问题。 - 2、Entry中的Key是将ThreadLocal对象进行包装成WeakReference，所以ThreadLocal对象没有被回收自然包装的WKR对象也不会被回收♻️。
第三个问题：既然存在内存泄漏风险，为何ThreadLocal还采用WKR的方式设计Entry的key呢？
首先要澄清ThreadLocal存在内存泄露风险原因是复杂的，多种场景柔和在一起导致的（Web应用前端是使用tomcat线程池，首先线程不会释放，那么同生同死的ThreadLocalMap就一直存活，加大了内存泄漏的风险 ）和Entry的Key设计成弱引用没有关系！。
原因是：ThreadLocalMap的设计中已经考虑到这种情况，也加上了一些防护措施：在ThreadLocal的get(),set(),remove()的时候都会清除线程ThreadLocalMap里所有key为null的value。
同时ThreadLocalMap采用弱引用的的设计优势：
-
引用的ThreadLocal的对象被回收了，由于ThreadLocalMap持有ThreadLocal的弱引用，即使没有手动删除，ThreadLocal也会被回收。【
WKR加速了ThreadLocal回收♻️】 -
如果设计成强引用：引用的ThreadLocal的对象被回收了，但是
ThreadLocalMap还持有ThreadLocal的强引用，如果没有手动删除，ThreadLocal不会被回收，导致Entry内存泄漏。
第四个问题：眼尖的同学会问了为什么第一个例子中WeakReference<User> weakReference = new WeakReference<User>(new User("xiali", "123", "男", 18)); 为甚么会被Yonggc回收♻️掉呢？
将第一个列子改一下：
public class WeakReferenceTest {
public static void main(String[] args) throws InterruptedException {
User user = new User("xiali", "123", "男", 18);
WeakReference<User> weakReference = new WeakReference<User>(user);
System.out.println("beforeGC:" + weakReference.get());
// 触发yonggc
allactionMemory();
TimeUnit.SECONDS.sleep(5);
System.out.println("afterGC:" + weakReference.get());
}
public static void allactionMemory() {
int size = 1024 * 1024 * 12;
int len = size / (10 * 1024);
List<byte[]> list = new ArrayList<byte[]>();
for (int i = 0; i < len; i++) {
try {
byte[] bytes = new byte[10 * 1024];
list.add(bytes);
} catch (Exception e) {
e.printStackTrace();
} finally {
}
}
}
static class User {
private String userName;
private String password;
private String sex;
private int age;
public User(String userName, String password, String sex, int age) {
this.userName = userName;
this.password = password;
this.sex = sex;
this.age = age;
}
@Override
public String toString() {
return "User{" +
"userName='" + userName + '\'' +
", password='" + password + '\'' +
", sex='" + sex + '\'' +
", age=" + age +
'}';
}
}
}
结果和ThreadLocal原理是一样的：User经过Yonggc回收♻️依然不能进行清理掉。
强引用与弱引用同时指向user的内存地址！
有且只有弱引用指向user内存地址，YongGC执行♻️时才能将WeakReference回收掉。
第五个问题：从WKR & ThreadLocal 设计中思考🤔日后开发中能提升什么❓
-
生命周期比较长的对象，与其相关的对象也会导致生命周期变长！通过WKR可以实现解耦，从而加速无关对象的GC回收♻️。
