java手动回收_浅谈java是如何做资源回收补救的
学习java的过程,我们经常谈论一个对象的回收,尤其是资源类型,如果没有显示的关闭,对象就被回收了,说明出现了资源泄漏。java本身为了防止这种情况,做了一些担保的方式,确保可以让未关闭的资源合理回收掉。
finalize回收
finalize方式是java对象被回收时触发的一个方法。java的很多资源对象,都是在finalize中写了担保的方法。
/**
* Ensures that the close
method of this file input stream is
* called when there are no more references to it.
*
* @exception IOException if an I/O error occurs.
* @see java.io.FileInputStream#close()
*/
protected void finalize() throws IOException {
if ((fd != null) && (fd != FileDescriptor.in)) {
/* if fd is shared, the references in FileDescriptor
* will ensure that finalizer is only called when
* safe to do so. All references using the fd have
* become unreachable. We can call close()
*/
close();
}
}
上面是FileInputStream的finalize方法,在方法被调用时,会检测文件描述符是否存在,如果存在的话就调用close方法。来确保资源的回收。
finalize方法在我们学习java的时候都并不推荐进行重写,也不推荐写复杂的逻辑在里面,主要是因为gc的时候,都会调用这个方法,如果执行的内容太多,就会导致gc被拖长。影响程序的正常运行。而且这里也只是做一个简单的担保。大部分希望的还是编写代码的人可以调用close。这样在做判断的时候就结束了,而不用真正的调用关闭的代码。
Cleaner回收
在DirectByteBuffer中,使用了一个Cleaner对象进行补救的。
unsafe.setMemory(base, size, (byte) 0);
if (pa && (base % ps != 0)) {
// Round up to page boundary
address = base + ps - (base & (ps - 1));
} else {
address = base;
}
cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
att = null;
申请完资源后,会创建一个Deallocator对象。
private static class Deallocator
implements Runnable
{
private static Unsafe unsafe = Unsafe.getUnsafe();
private long address;
private long size;
private int capacity;
private Deallocator(long address, long size, int capacity) {
assert (address != 0);
this.address = address;
this.size = size;
this.capacity = capacity;
}
public void run() {
if (address == 0) {
// Paranoia
return;
}
unsafe.freeMemory(address);
address = 0;
Bits.unreserveMemory(size, capacity);
}
}
Deallocator的run方法中就进行了资源的释放。执行的时机就是靠 Cleaner来触发的。
Cleaner是PhantomReference的子类,PhantomReference是Reference的子类。
在中有一个ReferenceHandler
private static class ReferenceHandler extends Thread {
他的run方法就是调用cleaner里的clean方法。这个线程是在静态块里启动起来的。
Thread handler = new ReferenceHandler(tg, "Reference Handler");
/* If there were a special system-only priority greater than
* MAX_PRIORITY, it would be used here
*/
handler.setPriority(Thread.MAX_PRIORITY);
handler.setDaemon(true);
handler.start();
SharedSecrets.setJavaLangRefAccess(new JavaLangRefAccess() {
@Override
public boolean tryHandlePendingReference() {
return tryHandlePending(false);
}
});
于此同时,并且给SharedSecrets设置了一个JavaLangRefAccess。
调用clean方法的过程在tryHandlePending里,这里的参数很重要。
static boolean tryHandlePending(boolean waitForNotify) {
Reference r;
Cleaner c;
try {
synchronized (lock) {
if (pending != null) {
r = pending;
// 'instanceof' might throw OutOfMemoryError sometimes
// so do this before un-linking 'r' from the 'pending' chain...
c = r instanceof Cleaner ? (Cleaner) r : null;
// unlink 'r' from 'pending' chain
pending = r.discovered;
r.discovered = null;
} else {
// The waiting on the lock may cause an OutOfMemoryError
// because it may try to allocate exception objects.
if (waitForNotify) {
lock.wait();
}
// retry if waited
return waitForNotify;
}
}
} catch (OutOfMemoryError x) {
// Give other threads CPU time so they hopefully drop some live references
// and GC reclaims some space.
// Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above
// persistently throws OOME for some time...
Thread.yield();
// retry
return true;
} catch (InterruptedException x) {
// retry
return true;
}
waitForNotify是true的时候,在没有回收对象的时候,会进入阻塞,然后等ooe。外层是个死循环,就会被再次调用到,下次进来的时候就可以出发clean了。
ReferenceHandler是管理机制的一种。
还有一种就是SharedSecrets调用tryHandlePending(false)。
在另外一个类,bits里
final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess();
// retry while helping enqueue pending Reference objects
// which includes executing pending Cleaner(s) which includes
// Cleaner(s) that free direct buffer memory
while (jlra.tryHandlePendingReference()) {
if (tryReserveMemory(size, cap)) {
return;
}
}
在做reserveMemory的时候,会从SharedSecrets来调用tryHandlePending(false)。这里又变相的进行了一次回收。
小结
java回收利用两种机制。一种是finalize,一种是Cleaner。其中Cleaner一部分依赖oome触发一次回收,一部分利用reserveMemory中做一次回收。
到此这篇关于浅谈java是如何做资源回收补救的的文章就介绍到这了,更多相关java 资源回收补救内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
java手动回收_浅谈java是如何做资源回收补救的相关推荐
- java对象头_浅谈java对象结构 对象头 Markword
概述 对象实例由对象头.实例数据组成,其中对象头包括markword和类型指针,如果是数组,还包括数组长度; | 类型 | 32位JVM | 64位JVM| | ------ ---- | ----- ...
- java bitset用途_浅谈Java BitSet使用场景和代码示例
搜索热词 @H_502_0@一.什么是BitSet? @H_502_0@ 注:以下内容来自JDK API: @H_502_0@ BitSet类实现了一个按需增长的位向量.位Set的每一个组件都有一个b ...
- java 多线程同步_浅谈Java多线程(状态、同步等)
Java多线程是Java程序员必须掌握的基本的知识点,这块知识点比较复杂,知识点也比较多,今天我们一一来聊下Java多线程,系统的整理下这部分内容. 一.Java中线程创建的三种方式: 1.通过继承T ...
- java同名函数_浅谈Java 继承接口同名函数问题
在Java中如果一个类同时继承接口A与B,并且这两个接口中具有同名方法,会怎么样? 动手做实验: interface A{ void fun(); } interface B{ void fun(); ...
- java gc 可以对方法区进行回收_浅谈 Java 之 GC
阅读本文假设你对java内存模型已有一些了解. 1.Java虚拟机中哪些内存需要回收? 先来看看jvm内存模型,如下图 线程隔离的区域随线程而生,随线程而灭:程序计数器可保存着虚拟机字节码指令的地址( ...
- java为什么要分代回收_浅谈Java堆内存分代回收
1.概述 与C++不同的是, 在Java中我们无需关心对象占用空间的释放, 这主要得益于Java中的垃圾处理器(简称GC)帮助我们自动的进行对象占用空间的释放. 下面我们带着几个问题来学习: 堆内存是 ...
- java并发计数器_浅谈java并发之计数器CountDownLatch
CountDownLatch简介 CountDownLatch顾名思义,count + down + latch = 计数 + 减 + 门闩(这么拆分也是便于记忆=_=) 可以理解这个东西就是个计数器 ...
- java list翻转_浅谈Java数据结构中的常见问题
1.常用数据结构 数据结构是指相互之间存在着一种或多种关系的数据元素的集合和该集合中数据元素间的关系组成.常用的数据有:数组.栈.队列.链表.树.图.堆.散列表. 1)数组:在内存中连续存储多个元素的 ...
- java反射 用处_浅谈Java反射
一.何为反射 反射就是对于任何一个类都能知道这个类的的所有属性和方法,并且对于任何一个对象都能调用他的属性和方法,而且能修改其属性. 二.反射的作用 就我的理解来看,通常我们在写代码的时会非常强调代码 ...
最新文章
- Windows_Server_2008_R2_AD_DS架构-第06部分_FSMO、AD的诊断及排故
- linux kernel and user space通信机制,Linux内核与用户空间通信机制研究.pdf
- java lombok.getter_lombok注解Getter和Setter的使用
- xshell添加脚本
- linux挂载和卸载
- Docker for windows 10
- List集合相关应用
- 医生c语言测试卷b卷的答案,合肥工业大学C语言期中测试题_B卷
- python的gc模块_Python的内存泄漏及gc模块的使用分析
- ospf学习笔记-7种状态
- java socket聊天_java_基于Java Socket实现一个简易在线聊天功能(一),最近做了一个项目,其中有一 - phpStudy...
- paip.Answer 3.0 注册功能SQL注入漏洞解决方案
- java 链接kafka单机版_kafka单机环境搭建及其基本使用
- 如何自己编写JDK帮助文档
- 程序匠人 - 程序调试(除错)过程中的一些雕虫小技
- 反黄软件测试工程师,谁才是反黄卫士?五款反黄软件横向评测
- OpenWrt的USB网口驱动使用
- 查看电脑(服务器)ip地址与名称
- Dirichlet Multinomial Mixtures (DMM)的R实现
- laravel会话控制和缓存操作