为什么我会收到“打开的文件太多”的信息错误？

发布于 2024-12-06 18:26:20 字数 1036 浏览 2 评论 0原文

我发现自己必须在 Groovy 脚本中显式调用 System.gc() 以防止出现如下错误。为什么垃圾收集器不为我做这件事？我可以做些什么来使其进行垃圾收集以防止这些错误（也许是 JAVA_OPTS）？

Caught: java.util.concurrent.ExecutionException: org.codehaus.groovy.runtime.InvokerInvocationException: java.io.IOException: Cannot run program "ls": java.io.IOException: error=24, Too many open files
    at groovyx.gpars.GParsPool.runForkJoin(GParsPool.groovy:305)
    at UsageAnalyzer$_run_closure2_closure6.doCall(UsageAnalyzer.groovy:36)
    at groovyx.gpars.GParsPool$_withExistingPool_closure1.doCall(GParsPool.groovy:170)
    at groovyx.gpars.GParsPool$_withExistingPool_closure1.doCall(GParsPool.groovy)
    at groovyx.gpars.GParsPool.withExistingPool(GParsPool.groovy:169)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:141)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:117)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:96)
    at UsageAnalyzer$_run_closure2.doCall(<removed>)
    at UsageAnalyzer.run(<removed>)

该堆栈跟踪来自并行程序，但它也发生在顺序程序中。

原文

I find myself having to explicitly call System.gc() in my Groovy scripts to prevent errors like the one below. Why doesn't the garbage collector do this for me? Is there something I can do to cause it to garbage collect to prevent these errors (maybe JAVA_OPTS)?

Caught: java.util.concurrent.ExecutionException: org.codehaus.groovy.runtime.InvokerInvocationException: java.io.IOException: Cannot run program "ls": java.io.IOException: error=24, Too many open files
    at groovyx.gpars.GParsPool.runForkJoin(GParsPool.groovy:305)
    at UsageAnalyzer$_run_closure2_closure6.doCall(UsageAnalyzer.groovy:36)
    at groovyx.gpars.GParsPool$_withExistingPool_closure1.doCall(GParsPool.groovy:170)
    at groovyx.gpars.GParsPool$_withExistingPool_closure1.doCall(GParsPool.groovy)
    at groovyx.gpars.GParsPool.withExistingPool(GParsPool.groovy:169)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:141)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:117)
    at groovyx.gpars.GParsPool.withPool(GParsPool.groovy:96)
    at UsageAnalyzer$_run_closure2.doCall(<removed>)
    at UsageAnalyzer.run(<removed>)

This stack trace is from a parallel program but it happens in sequential programs as well.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一瞬间的火花 2024-12-13 18:26:20

当您使用 groovy 时，您可以使用方便的方法，例如 File.withReader()、File.withWriter()、File.withInputStream()< /code>, InputStream.withStream() 确保资源完全关闭。这比使用 Java 的 try ..finally 习惯用法要简单，因为不需要显式调用 close()，或者在 try 之外声明变量代码>块。

例如从文件中读取。

File f = new File('/mumble/mumble/')
f.withReader{ r -> 
   // do stuff with reader here
}

As you're using groovy, you can use the convenient methods such as File.withReader(), File.withWriter(), File.withInputStream(), InputStream.withStream() to ensure resources get closed cleanly. This is less cumbersome than using Java's try .. finally idiom, as there's not need to explicitly call close(), or declare a variable outside the try block.

e.g. to read from a file.

File f = new File('/mumble/mumble/')
f.withReader{ r -> 
   // do stuff with reader here
}

回复收藏 0 原文

习惯那些不曾习惯的习惯 2024-12-13 18:26:20

一定要查找您打开文件或流的任何位置，并确保关闭它们。像这样包裹它们通常是有益的：

final InputStream in = ...;
try
{
    // Do whatever.
}
finally
{
    // Will always close the stream, regardless of exceptions, return statements, etc.
    in.close();
}

Definitely look for any place you open files or streams and make sure you close them. It's often beneficial to wrap them like this:

final InputStream in = ...;
try
{
    // Do whatever.
}
finally
{
    // Will always close the stream, regardless of exceptions, return statements, etc.
    in.close();
}

回复收藏 0 原文

~没有更多了~