有什么好的例子可以证明Android中的文件描述符泄漏吗?我在某个地方读到,如果我们不关闭流(例如FileInputStream
或FileOutputStream
(,就会发生这种情况,但我找不到任何好的参考示例来证明它
请分享一些博客/代码片段。非常感谢。
因为Dalvik的FileInputStream在垃圾收集时会自行关闭(OpenJDK/Oracle也是如此(,所以实际泄漏文件描述符的情况比您想象的要少。当然,在GC运行之前,文件描述符将被"泄漏",因此根据您的程序,可能需要一段时间才能回收它们。
为了实现更永久的泄漏,您必须通过在内存中的某个位置保留对流的引用来防止流被垃圾收集。
这里有一个简短的例子,它每1秒加载一个属性文件,并跟踪它的每次更改:
public class StreamLeak {
/**
* A revision of the properties.
*/
public static class Revision {
final ZonedDateTime time = ZonedDateTime.now();
final PropertiesFile file;
Revision(PropertiesFile file) {
this.file = file;
}
}
/*
* Container for {@link Properties} that implements lazy loading.
*/
public static class PropertiesFile {
private final InputStream stream;
private Properties properties;
PropertiesFile(InputStream stream) {
this.stream = stream;
}
Properties getProperties() {
if(this.properties == null) {
properties = new Properties();
try {
properties.load(stream);
} catch(IOException e) {
e.printStackTrace();
}
}
return properties;
}
@Override
public boolean equals(Object o) {
if(o instanceof PropertiesFile) {
return ((PropertiesFile)o).getProperties().equals(getProperties());
}
return false;
}
}
public static void main(String[] args) throws IOException, InterruptedException {
URL url = new URL(args[0]);
LinkedList<Revision> revisions = new LinkedList<>();
// Loop indefinitely
while(true) {
// Load the file
PropertiesFile pf = new PropertiesFile(url.openStream());
// See if the file has changed
if(revisions.isEmpty() || !revisions.getLast().file.equals(pf)) {
// Store the new revision
revisions.add(new Revision(pf));
System.out.println(url.toString() + " has changed, total revisions: " + revisions.size());
}
Thread.sleep(1000);
}
}
}
由于延迟加载,我们将InputStream保留在PropertiesFile中,每当我们创建新的Revision时,它都会被保留,并且由于我们从不关闭流,我们将在此处泄漏文件描述符。
现在,当程序终止时,操作系统将关闭这些打开的文件描述符,但只要程序正在运行,它就会继续泄漏文件描述符,这可以通过使用lsof:看出
$ lsof | grep pf.properties | head -n 3
java 6938 raniz 48r REG 252,0 0 262694 /tmp/pf.properties
java 6938 raniz 49r REG 252,0 0 262694 /tmp/pf.properties
java 6938 raniz 50r REG 252,0 0 262694 /tmp/pf.properties
$ lsof | grep pf.properties | wc -l
431
如果我们强制GC运行,我们可以看到其中大部分都被返回了:
$ jcmd 6938 GC.run
6938:
Command executed successfully
$ lsof | grep pf.properties | wc -l
2
剩下的两个描述符是存储在修订版中的描述符。
我在我的Ubuntu机器上运行了这个,但如果在Android上运行,输出看起来会很相似。
InputStream in;
try {
in = new BufferedInputStream(socket.getInputStream());
// Do your stuff with the input stream
} catch (Exception e) {
// Handle your exception
} finally {
// Close the stream here
if (in != null) {
try {
in.close();
} catch (IOException e) {
Log.e(TAG, "Unable to close stream: " + e);
}
}
}
这个想法是关闭finally
块中的文件描述符。无论成功完成还是发生异常,文件描述符都将正确关闭。
现在,如果您正在寻找一些东西来演示如何不正确地执行此操作,只需将此代码包装在while(1)
循环中,注释掉in.close()
行,并在catch块中放入break;
,这样当它爆炸时,您就可以脱离无限循环。
InputStream in; try { in = new FileInputStream(new File("abc"); in.read(); // Do some stuff with open fileinputstream // If an exception is generated, inputstream object will not be closed // as the next statement will not be executed, instead jumping to // the catch block. this will cause a leak of the fd assigned to file // "abc" while opening it in.close()' } catch (Exception e) { // Handle your exception }