什么是内存泄露
定义&＃xff1a;当生命周期长的实例 L 不合理地持有一个生命周期短的实例 S&＃xff0c;导致 S 实例无法被正常回收
代码例子
public class AppSettings {
private Context mAppContext;
private static AppSettings sInstance &＃61; new AppSettings();
//some other codes
public static AppSettings getInstance() {
return sInstance;
}
public final void setup(Context context) {
mAppContext &＃61; context;
}
}
解释
上面的代码可能会发生内存泄露
我们调用 1AppSettings.getInstance.setup() 传入一个Activity实例
当上述的 Activity 退出时&＃xff0c;由于被 AppSettings 中属性 mAppContext 持有&＃xff0c;进而导致内存泄露。
为什么上面的情况就会发生内存泄露
以 JAVA 为例&＃xff0c;GC 回收对象采用GC Roots强引用可到达机制。
Activity实例被AppSettings.sInstance持有
AppSettings.sInstance由于是静态&＃xff0c;被AppSettings类持有
AppSettings类被加载它的类加载器持有
而类加载器就是GC Roots的一种由于上述关系导致Activity实例无法被回收销毁。
ps: 内存泄漏&＃xff0c;其实就是本来应该被回收的对象&＃xff0c;因为被更长生命周期的对象持有&＃xff0c;而无法回收的情况。
验证是否引起内存泄露
因此&＃xff0c;想要证明未关闭的文件流是否导致内存泄露&＃xff0c;需要查看文件流是否是GC Roots强引用可到达。
示例代码1(辅助验证GC 发生)
import java.io.BufferedReader;
import java.io.Reader;
class MyBufferedReader(&＃96;in&＃96;: Reader?) : BufferedReader(&＃96;in&＃96;) {
protected fun finalize() {
println("MyBufferedReader get collected")
}
}
示例代码2
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
findViewById(R.id.textview).setOnClickListener {
testInputStream()
}
}
private fun testInputStream() {
//需进入设置手动开启应用权限&＃xff0c;未处理运行时权限问题
val &＃96;is&＃96; &＃61; FileInputStream("/sdcard/a.txt")
val buf &＃61; MyBufferedReader(InputStreamReader(&＃96;is&＃96;))
var line &＃61; buf.readLine()
val sb &＃61; StringBuilder()
while (line !&＃61; null) {
sb.append(line).append("\n")
line &＃61; buf.readLine()
}
val fileAsString &＃61; sb.toString()
Log.i("MainActivity", "testInputStream.Contents : $fileAsString")
}
}
操作步骤
这里我们这样操作
点击textview视图&＃xff0c;触发多次testInputStream
过几秒后&＃xff0c;我们执行 heap dump。
我们使用 MAT 对上一步的dump文件进行分析(需进行格式转换)
分析结果
分析上图&＃xff0c;我们发现
FileInputStream 只被 FinalizerReference 这个类(GC Root)持有
上述持有的原因是&＃xff0c;FileInputStream重写了finalize&＃xff0c;会被加入到FinalizerReference的析构处理集合
上述引用会随着Finalizer守护线程处理后解除&＃xff0c;即FileInputStream实例彻底销毁。
所以&＃xff0c;我们再来操作一波&＃xff0c;验证上面的结论。
然后利用工具执行强制 GC 回收
过几秒后&＃xff0c;我们执行heap dump。
我们使用 MAT 对上一步的dump文件进行分析(需进行格式转换)
堆分析文件&＃xff0c;查找MyBufferedReader或者FileInputStream或者InputStreamReader 没有发现这些实例&＃xff0c;说明已经GC回收
出于谨慎考虑&＃xff0c;我们按照包名查找java.io在排除无关实例外&＃xff0c;依旧无法找到testInputStream中的实例。再次证明已经被GC回收
因而我们可以确定&＃xff0c;正常的使用流&＃xff0c;不会导致内存泄露的产生。
当然&＃xff0c;如果你刻意显式持有Stream实例&＃xff0c;那就另当别论了。
为什么需要关闭流
看图
如上图从左至右有三张表
file descriptor table 归属于单个进程
global file table(又称open file table) 归属于系统全局
inode table 归属于系统全局
从一次文件打开说起
当我们尝试打开文件 /path/myfile.txt
从 inode table 中查找到对应的文件节点
根据用户代码的一些参数(比如读写权限等)在 open file table 中创建 open file 节点
将上一步的 open file 节点信息保存&＃xff0c;在 file descriptor table 中创建 file descriptor
返回上一步的 file descriptor 的索引位置&＃xff0c;供应用读写等使用。
file descriptor 和流有什么关系
当我们这样 FileInputStream("/sdcard/a.txt") 会获取一个 file descriptor。
出于稳定系统性能和避免因为过多打开文件导致CPU和RAM占用居高的考虑&＃xff0c;每个进程都会有可用的file descriptor 限制。
所以如果不释放file descriptor&＃xff0c;会导致应用后续依赖file descriptor的行为(socket连接&＃xff0c;读写文件等)无法进行&＃xff0c;甚至是导致进程崩溃。
当我们调 用FileInputStream.close 后&＃xff0c;会释放掉这个 file descriptor。
因此到这里我们可以说&＃xff0c;不关闭流不是内存泄露问题&＃xff0c;是资源泄露问题(file descriptor 属于资源)。
不手动关闭会怎样
不手动关闭的真的会发生上面的问题么&＃xff1f;
其实也不完全是。
因为对于这些流的处理&＃xff0c;源代码中通常会做一个兜底处理。
以 FileInputStream 为例
/**
* Ensures that the close method of this file input stream is
* called when there are no more references to it.
*
* &＃64;exception IOException if an I/O error occurs.
* &＃64;see java.io.FileInputStream#close()
*/
protected void finalize() throws IOException {
// Android-added: CloseGuard support.
if (guard !&＃61; null) {
guard.warnIfOpen();
}
if ((fd !&＃61; null) && (fd !&＃61; FileDescriptor.in)) {
// Android-removed: Obsoleted comment about shared FileDescriptor handling.
close();
}
}
是的&＃xff0c;在finalize方法中有调用close来释放file descriptor.
但是finalize方法执行速度不确定&＃xff0c;不可靠
所以&＃xff0c;我们不能依赖于这种形式&＃xff0c;还是要手动调用close来释放file descriptor。
ps: 也就是说不会造成内存泄漏。实际导致的是资源泄漏&＃xff0c;因为 finalize 回收的线程优先级非常低。
关闭流实践
手动关闭
private String readFirstLine() throws FileNotFoundException {
BufferedReader reader &＃61; new BufferedReader(new FileReader("test.file"));
try {
return reader.readLine();
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
reader.close();
} catch (IOException e) {
e.printStackTrace();
}
}
return null;
}
TWR
Java 7 之后&＃xff0c;可以使用 try-with-resource 方式处理
String readFirstLineFromFile(String path) throws IOException {
try (BufferedReader br &＃61; new BufferedReader(new FileReader(path))) {
return br.readLine();
}
}
个人收获
知识在于存疑
对于最常见的文件不关闭会内存泄漏&＃xff0c;99% 的程序员都知道。
但是为什么会内存泄漏&＃xff0c;估计知道的人少之又少。
jvm
jvm 的相关命令&＃xff0c;一直停留于表面。
没有真正的去使用。
文件系统
操作系统的文件系统&＃xff0c;如果没有系统学习&＃xff0c;很多东西都是不知道的。
参考资料
京公网安备 11010802041100号