最近接触了一些面试者,在面试过程中有涉及到内存泄露的问题,其中有不少人回答说,如果文件打开后,没有关闭会导致内存泄露。当被继续追问,为什么会导致内存泄露时,大部分人都没有回答出来。
本文将具体讲一讲 文件(流)未关闭与内存泄露的关系。
L
不合理地持有一个生命周期短的实例S
,导致S
实例无法被正常回收1 2 3 4 5 6 7 8 9 10 11 12 13 | public class AppSettings { private Context mAppContext; private static AppSettings sInstance = new AppSettings(); //some other codes public static AppSettings getInstance() { return sInstance; } public final void setup(Context context) { mAppContext = context; } } |
---|
上面的代码可能会发生内存泄露
AppSettings.getInstance.setup()
传入一个Activity
实例Activity
退出时,由于被AppSettings
中属性mAppContext
持有,进而导致内存泄露。为什么上面的情况就会发生内存泄露
GC Roots
强引用可到达机制。Activity
实例被AppSettings.sInstance
持有AppSettings.sInstance
由于是静态,被AppSettings
类持有AppSettings
类被加载它的类加载器持有GC Roots
的一种Activity
实例无法被回收销毁。因此,想要证明未关闭的文件流是否导致内存泄露,需要查看文件流是否是GC Roots
强引用可到达。
示例代码1(辅助验证GC 发生)
1 2 3 4 5 6 7 8 9 10 11 | package com.example.streamleakssample import java.io.BufferedReader import java.io.Reader class MyBufferedReader(`in`: Reader?) : BufferedReader(`in`) { protected fun finalize() { println("MyBufferedReader get collected") } } |
---|
示例代码2
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 | package com.example.streamleakssample import android.os.Bundle import android.support.v7.app.AppCompatActivity import android.util.Log import android.view.View import java.io.FileInputStream import java.io.InputStreamReader class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) findViewById<View>(R.id.textview).setOnClickListener { testInputStream() } } private fun testInputStream() { //需进入设置手动开启应用权限,未处理运行时权限问题 val `is` = FileInputStream("/sdcard/a.txt") val buf = MyBufferedReader(InputStreamReader(`is`)) var line = buf.readLine() val sb = StringBuilder() while (line != null) { sb.append(line).append("\n") line = buf.readLine() } val fileAsString = sb.toString() Log.i("MainActivity", "testInputStream.Contents : $fileAsString") } } |
---|
这里我们这样操作
testInputStream
heap dump
。分析上图,我们发现
FileInputStream
重写了finalize
,会被加入到FinalizerReference
的析构处理集合Finalizer
守护线程处理后解除,即FileInputStream
实例彻底销毁。所以,我们再来操作一波,验证上面的结论。
heap dump
。MyBufferedReader
或者FileInputStream
或者InputStreamReader
没有发现这些实例,说明已经GC回收java.io
在排除无关实例外,依旧无法找到testInputStream
中的实例。再次证明已经被GC回收因而我们可以确定,正常的使用流,不会导致内存泄露的产生。
当然,如果你刻意显式持有Stream实例,那就另当别论了。
首先我们看一张图
如上图从左至右有三张表
当我们尝试打开文件/path/myfile.txt
1.从inode table 中查找到对应的文件节点 2.根据用户代码的一些参数(比如读写权限等)在open file table 中创建open file 节点 3.将上一步的open file节点信息保存,在file descriptor table中创建 file descriptor 4.返回上一步的file descriptor的索引位置,供应用读写等使用。
FileInputStream("/sdcard/a.txt")
会获取一个file descriptor。FileInputStream.close
后,会释放掉这个file descriptor。因此到这里我们可以说,不关闭流不是内存泄露问题,是资源泄露问题(file descriptor 属于资源)。
不手动关闭的真的会发生上面的问题么? 其实也不完全是。
因为对于这些流的处理,源代码中通常会做一个兜底处理。以FileInputStream
为例
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | /** * Ensures that the <code>close</code> 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 { // Android-added: CloseGuard support. if (guard != null) { guard.warnIfOpen(); } if ((fd != null) && (fd != FileDescriptor.in)) { // Android-removed: Obsoleted comment about shared FileDescriptor handling. close(); } } |
---|
是的,在finalize方法中有调用close
来释放file descriptor.
但是finalize方法执行速度不确定,不可靠
所以,我们不能依赖于这种形式,还是要手动调用close
来释放file descriptor。
Java 7 之后,可以使用try-with-resource方式处理
1 2 3 4 5 6 | static String readFirstLineFromFile(String path) throws IOException { try (BufferedReader br = new BufferedReader(new FileReader(path))) { return br.readLine(); } } |
---|
Kotlin 可以使用use
1 2 3 | private fun readFirstLine(): String { BufferedReader(FileReader("test.file")).use { return it.readLine() } } |
---|
当然,还有最基础的手动关闭的形式
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | private String readFirstLine() throws FileNotFoundException { BufferedReader reader = 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; } |
---|