我是靠谱客的博主 纯真荷花,这篇文章主要介绍java的内存回收(1)内存的分配与回收都是jvm自动完成的,JDK 1.6之前的常量池实际就是在方法区,JDK 1.7及以后移动到堆中了,现在分享给大家,希望可以做个参考。

 

如果无用的堆内存中的对象在对内存中累计多了的话,等到大批用户一上来,系统的内存就会越来越小,系统响应速度自然变慢

因为java虽然有内存回收机制,但是我们作为开发人员也要显示的管理无用对象的释放,否则系统响应极慢,所以我们应注重内存回收,也要注重内存的分配,这样才能很好的利用有限的内存

使用new去申请分配空间,一个对象失去引用时方可回收

内存的分配与回收都是jvm自动完成的,

jvm的垃圾回收机制负责回收堆内存中除字符串池之外的对象,栈内存由别的机制回收内存,

JDK 1.6之前的常量池实际就是在方法区,JDK 1.7及以后移动到堆中了

new/反序列化/克隆均会申请分配内存

简单来讲,在内存回收方面jvm已经帮我们回收了不可达的无用对象,我们程序需要手动回收的是可达的无用对象,还需要回收字符串池中没有引用指向的字符串对象(解决java的内存泄漏,将引用指针赋值为null),内存中只存在的是可达的有用对象

我们从如下几个方面考虑内存回收

1jvm在核实决定回收一个java对象所占据的内存(对象处于不可达状态)

2jvm会不会漏掉回收某些java对象,使之造成内存泄漏(强引用所指向的系统再也用不到的对象不会被回收)

3jvm回收java对象所占用内存的实现细节(有向图管理,判断是否还有引用)

4jvm能否对不同java对象占用的内存区分对待,回收

5常见垃圾回收机制的实现细节是什么样的?(有向图管理)

1jvm回收java对象所占用内存的方法(一)实现细节(有向图管理,判断是否还有引用

jvm的垃圾回收机制采用有向图方式管理内存中的对象,将线程对象作为有向图的起始顶点,把引用变量和对象作为有向图的顶点,判断对象是否处于可达状态

对象在堆内存中的三种状态:可达状态/可恢复状态(在回收该对象前,系统调用可恢复对象的finalize方法进行资源清理,可以重新获得引用)/不可达状态(彻底失去引用)

注意:

通过这种方法进行垃圾回收并不是特别彻底,虽然垃圾回收机制会将不存在引用的对象回收了,但是有一些对象本身是无用的了,却还是有引用指向他,这样的无用对象垃圾回收机制是回收不了的,因此此处易发生内存泄漏

内存泄漏:存在无用的内存没有被回收回来,就是内存泄漏

2jvm回收java对象所占用内存的方法(二)实现细节(通过引用变量类型进行回收)

引用变量的分类?

强引用: 系统垃圾回收机制运行时,不管系统内存如何,强引用所指向的对象一定不会被回收

               当一个对象被强引用所引用时,jvm即使在系统内存十分紧张的情况下也是不会回收强引用所指向的java对象,

               因此有些强引用指向的对象就算以后不会用到,系统也不会回收,造成内存泄漏

软引用:系统垃圾回收机制运行时,看系统内存的情况,软引用指向的对象不一定会被回收

               系统内存不足时,系统会回收,系统内存足够时,不会被回收

弱引用:系统垃圾回收机制运行时,不管系统内存如何,弱引用所指向的对象一定会被回收

虚引用:跟踪对象被垃圾回收的状态,虚引用必须和引用队列联合使用

对于软引用,弱引用,虚引用,java提供le3个类SoftReference WeakReference  PhantomReference

SoftReference源码

复制代码
1
public class SoftReference<T> extends Reference<T> {
复制代码
1
static private long clock;
复制代码
1
private long timestamp;
复制代码
1
2
3
4
public SoftReference(T referent) { super(referent); this.timestamp = clock; }
复制代码
1
2
3
4
public SoftReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); this.timestamp = clock; }
复制代码
1
2
3
4
5
6
7
8
9
public T get() { T o = super.get(); if (o != null && this.timestamp != clock) this.timestamp = clock; return o; } }

WeakReference源码

复制代码
1
2
public class WeakReference<T> extends Reference<T> {
复制代码
1
2
3
4
public WeakReference(T referent) { super(referent); }
复制代码
1
2
3
4
5
public WeakReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); } }

PhantomReference源码

复制代码
1
2
public class PhantomReference<T> extends Reference<T> {
复制代码
1
2
3
public T get() { return null; }
复制代码
1
2
3
4
5
public PhantomReference(T referent, ReferenceQueue<? super T> q) { super(referent, q); } } 引用队列 ReferenceQueue
复制代码
1
public class ReferenceQueue<T> {
复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
public ReferenceQueue() { } private static class Null<S> extends ReferenceQueue<S> { boolean enqueue(Reference<? extends S> r) { return false; } } static ReferenceQueue<Object> NULL = new Null<>(); static ReferenceQueue<Object> ENQUEUED = new Null<>(); static private class Lock { }; private Lock lock = new Lock(); private volatile Reference<? extends T> head = null; private long queueLength = 0; boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */ synchronized (lock) { // Check that since getting the lock this reference hasn't already been // enqueued (and even then removed) ReferenceQueue<?> queue = r.queue; if ((queue == NULL) || (queue == ENQUEUED)) { return false; } assert queue == this; r.queue = ENQUEUED; r.next = (head == null) ? r : head; head = r; queueLength++; if (r instanceof FinalReference) { sun.misc.VM.addFinalRefCount(1); } lock.notifyAll(); return true; } } @SuppressWarnings("unchecked") private Reference<? extends T> reallyPoll() { /* Must hold lock */ Reference<? extends T> r = head; if (r != null) { head = (r.next == r) ? null : r.next; // Unchecked due to the next field having a raw type in Reference r.queue = NULL; r.next = r; queueLength--; if (r instanceof FinalReference) { sun.misc.VM.addFinalRefCount(-1); } return r; } return null; } public Reference<? extends T> poll() { if (head == null) return null; synchronized (lock) { return reallyPoll(); } } public Reference<? extends T> remove(long timeout) throws IllegalArgumentException, InterruptedException { if (timeout < 0) { throw new IllegalArgumentException("Negative timeout value"); } synchronized (lock) { Reference<? extends T> r = reallyPoll(); if (r != null) return r; long start = (timeout == 0) ? 0 : System.nanoTime(); for (;;) { lock.wait(timeout); r = reallyPoll(); if (r != null) return r; if (timeout != 0) { long end = System.nanoTime(); timeout -= (end - start) / 1000_000; if (timeout <= 0) return null; start = end; } } } } public Reference<? extends T> remove() throws InterruptedException { return remove(0); } }j

jvm如何帮我们回收了不可达的无用对象?采用了什么垃圾回收算法?

现行的垃圾回收器采用分代的方式来采用不同的回收设计,

分代的基本思想是根据对象的生存的时间的长短把堆内存分为三代:Young/Old/Permanent

young代的内存会先被回收,而且使用专门的回收算法(复制算法)来回收young代的内存,

对于old代的回收频率则要低得多,也会采用专门的回收算法

开发者管理内存的技巧?----减少内存的分配,减小java的内存泄漏---帮助垃圾回收器回收

1尽早释放无用对象的引用,让垃圾回收机制回收可达的无用对象

2尽量使用直接量,减少对象的创建,多使用字符串缓存池String/Byte/Integer/Short/Chrracter/Double/Float/Boolean

减少不必要的内存浪费String a=“xx"√   Stirng a=new String("xx")×,减少了堆内存对象的产生,减少内存分配,但是如果a在指向其他的字符串对象,也会存在内存泄漏的现象,即xx存在在字符串池中,不会被垃圾回收

3进行字符串拼接时,尽量选用StringBuilder/StringBuffer,减少临时对象,减少内存的分配

4缓存经常使用的对象,数据库连接池,(用空间换时间),减少内存的分配

5避免在经常调用的方法,循环中创建java对象,减少内存的分配

 

最后

以上就是纯真荷花最近收集整理的关于java的内存回收(1)内存的分配与回收都是jvm自动完成的,JDK 1.6之前的常量池实际就是在方法区,JDK 1.7及以后移动到堆中了的全部内容,更多相关java的内存回收(1)内存的分配与回收都是jvm自动完成的,JDK内容请搜索靠谱客的其他文章。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(65)

评论列表共有 0 条评论

立即
投稿
返回
顶部