我检查了我的java代码,coverity分析发现了这个资源泄漏错误。
@Before
public void init() {
(1) Event alloc_fn: A new resource is returned from allocation method "deleteFrom". (The virtual call resolves to "org.jooq.impl.DefaultDSLContext.deleteFrom".)
(2) Event leaked_resource: Failing to save or close resource created by "dslContext.deleteFrom(com.nurego.bizops.metering.common.jooq.nongen.tables.MyTable.MYTABLE)" leaks it.
dslContext.deleteFrom(MyTable.MYTABLE).execute();
}
``` `dslContext.close()` 已经在发情前的方法中使用。
我应该这样做吗?
DeleteUsingStep step = dslContext.deleteFrom(MyTable.MYTABLE);
step.execute();
step.close();
还是有更好的解决办法?
1条答案
按热度按时间ccgok5k51#
直到jooq 3.13
Java7和Java8之间关于
AutoCloseable
,请参阅javadoc:java 7版本
不再需要时必须关闭的资源。
注意“必须”一词。
java 8版本
一种对象,在关闭前可能会保留资源(如文件或套接字句柄)。自动关闭对象的close()方法在退出try with resources块时自动调用,该块的对象已在资源规范标头中声明。这种结构确保了及时发布,避免了资源耗尽异常和可能发生的错误。
api注解:
基类实现autocloseable是可能的,而且事实上是常见的,即使不是它的所有子类或示例都将拥有可发布的资源。对于必须以完全通用的方式操作的代码,或者当已知autocloseable示例需要资源释放时,建议使用try with resources构造。但是,当使用支持基于i/o和非i/o的表单的stream之类的工具时,在使用非i/o表单时,try with resources块通常是不必要的。
这样做(可能)是为了
Stream
延伸AutoCloseable
为了方便使用流与try-with-resources
,尽管事实上几乎所有的流都不是资源丰富的。不幸的是,当涉及到自动关闭检测时,这使得大多数静态分析工具毫无用处。他们可能已经为流硬编码了一个异常,但不是为流
DSLContext
.在使用jooq时,可以安全地忽略这些错误
DSLContext
.从jooq3.14开始
这是jooq新用户经常遇到的问题,可能被认为是api设计缺陷。jooq3.14将删除
AutoCloseable
从DSLContext
超级类型并提供专用CloseableDSLContext
相反,它只从相关方法返回:https://github.com/jooq/jooq/issues/10512