java 代码扫描_静态代码扫描 (四)——Java 资源关闭研究

最新推荐文章于 2024-08-13 06:00:00 发布

东京不太热

最新推荐文章于 2024-08-13 06:00:00 发布

阅读量401

点赞数

文章标签： java 代码扫描

本文链接：https://blog.csdn.net/weixin_33485981/article/details/114425889

版权

这是静态代码扫描系列文章的第四篇，前三篇文章介绍了如何使用 PMD 和 Findbugs 自定义规则。

我们火线团队最近一直在研究 java 资源关闭的检查规则，发现市面上开源的工具针对资源关闭的检测都存在一定不足，同时也无法满足我们业务的需求。所以我们针对资源关闭进行了深度的研究，取得了一些不错的进展，但是过程的艰辛也远超了我们的预料。现在就跟大家聊聊我们的心路历程，从为什么开始。

1. 为什么要手动关闭 Java 资源对象？

首先解释 Java 的资源对象，它主要包括 IO 对象，数据库连接对象。比如常见的 InputStream、OutputStream、Reader、Writer、Connection、Statement、ResultSet、Socket 等等，先代码列举一个示例：

FileInputStream f = new FileInputStream("sample.txt");

f.close();//f对象即需要手动关闭的资源对象

上述代码中 f 对象即需要手动关闭的资源对象。

如果类似的资源对象没有及时的手动关闭，这个对象就会一直占据内存，当这样的对象越来越多，那内存被占用的就会越来越多，久而久之就可能造成 OutOfMemory，俗称内存溢出。

这时应该有人会问，Java 不是有自己的垃圾回收机制 GC 么？不是可以自动回收么？

这个问题问的好，我也一度非常困惑。

首先我们先了解一下 GC 的原理：

在 Java 中，当没有对象引用指向原先分配给某个对象的内存时，该内存便成为垃圾。JVM 的一个系统级线程会自动释放该内存块。垃圾回收意味着程序不再需要的对象是"无用信息"，这些信息将被丢弃。当一个对象不再被引用的时候，内存回收它占领的空间，以便空间被后来的新对象使用。

首先 GC 只能回收内存。至于各种 stream 之类，他们下边一般还开启了各种其他的系统资源，比如文件，比如输入输出设备(键盘/屏幕等)，等等。而这些设备第一是不能自动关闭(因为谁知道你程序要用它到什么时候啊)，另一个系统内数量有限(比如键盘/屏幕同一时间只有一个)。最后，文件和数据库连接之类的东西还存在读写锁定的问题。这些都导致用户必须手动处理这些资源的开启和关闭。

其次为了 “避免” 程序员忘了自己释放那些资源，Java 提供了 finalizer、PhantomReference 之类的机制来让程序员向 GC 注册 “自动回调释放资源” 的功能。但 GC 回调它们的时机不确定，所以只应该作为最后手段来使用，主要手段还是自己关闭最好。

PS：关于 GC 其实有很多的知识可以深度挖掘，比如各种回收算法，finalize() 方法等等，大家感兴趣的话可以自行搜索研究，我就不班门弄斧了。

2. 怎样正确的手动关闭 Java 资源对象？

先说一种最常见的关闭方式，在 finally 中进行关闭：

FileInputStream f;

try{

f= new FileInputStream("sample.txt");

//something that uses f and sometimes throws an exception

}

catch(IOException ex){

/* Handle it somehow */

}