java.net.SocketException：打开的文件太多

我有一个java应用程序运行得很好（在Ubuntu 10.04上）几个小时，直到它命中“java.net.SocketException：太多打开的文件”。 可以在此处找到Sender.java的代码

是因为我为每个线程创建了一个新的HttpPut和HttpPost实例吗？ 我正在使用apache-commons HTTPClient 4。

这是exception日志：

 java.net.SocketException: Too many open files at java.net.Socket.createImpl(Socket.java:414) at java.net.Socket.connect(Socket.java:544) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:123) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:133) at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149) at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554) at com.marketplace.io.Sender.doBasicHttpPost(Sender.java:434) at com.marketplace.io.Sender.appVisualExists(Sender.java:223) at com.marketplace.io.Sender.addVisualToCollection(Sender.java:350) at com.marketplace.service.ImageThread.run(ImageThread.java:136) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) 

Answer 1

在第438行，您将响应作为流并将其转换为字节数组。 entity.getContent（）返回的InputStream不会关闭。 这可能导致了这个问题。 此外，出于相关原因，不推荐使用HttpEntity.consumeContent（） 。

Answer 2

“java.net.SocketException：打开的文件太多”可以看到任何Java Server应用程序，例如Tomcat，Weblogic，WebSphere等，客户端经常连接和断开连接。

请注意， 套接字连接被视为文件，它们使用文件描述符，这是一种有限的资源。

不同的操作系统对它们可以管理的文件句柄数有不同的限制。

简而言之，这个错误即将到来，因为客户端经常连接和断开连接。如果您想要处理它，您有两个选择：

1）增加每个进程的打开文件句柄或文件描述符的数量。

在基于UNIX的操作系统（例如Ubuntu或Solaris）中，您可以使用命令ulimit -a来查找每个进程允许的打开文件句柄数。

 $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 256 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2048 virtual memory (kbytes, -v) unlimited 

您可以看到，打开文件（-n）256，这意味着每个进程只允许256个打开的文件句柄。 如果您的Java程序，记住Tomcat，weblogic或任何其他应用程序服务器都是Java程序并且它们在JVM上运行，超过此限制，则会抛出java.net.SocketException：打开太多文件错误。

您可以通过将ulimit -n更改为更大的数字（例如4096）来更改此限制，但是建议使用UNIX系统管理员，如果您有单独的UNIX支持团队，则可以更好地升级到它们。

2）减少操作系统中TIME_WAIT状态的超时

在基于UNIX的系统中，您可以在/ proc / sys / net / ipv4 / tcp_fin_timeout文件中查看当前配置。

在基于Windows的系统中，您可以在Windows注册表中看到此信息。 您可以通过以下步骤更改Windows中的TCPTIME_WAIT超时：

 1) Open Windows Registry Editor, by typing regedit in run command window 2) Find the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters 3) Add a new key value pair TcpTimedWaitDelay asa decimal and set the desired timeout in seconds (60-240) 4) Restart your windows machine. 

Answer 3

您可能还想检查linux最大打开文件限制。 此相关链接适用于基于Java的定制产品，但它很好地解释了解决问题所需的步骤。

Answer 4

（解决）

我最近有同样的错误，因为DataBase Server上的var / log是Full。

 #df -h S.ficheros Size Used Avail Use% Montado en /dev/cciss/c0d0p3 126G 126G 0G 100% /var #echo "">/var/log/postgresql/postgresql.log 

现在，错误消失了！

重要的：看看登录postgresql.log的内容，查看你的postgresql.conf

再见
@_jpgo

Answer 5

我通过关闭finally块中的连接来解决问题。

 public static String postMethod(String jsonStr,String sendUrl){ String resultJson = ""; HttpClient httpClient = new HttpClient(); PostMethod post = new PostMethod(sendUrl); post.setRequestHeader("Content-Type","application/x-www-form-urlencoded;charset=utf-8"); NameValuePair[] param = { new NameValuePair("message",jsonStr)} ; post.setRequestBody(param); try { httpClient.executeMethod(post); resultJson = post.getResponseBodyAsString(); } catch (HttpException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); }finally{ post.releaseConnection(); ((SimpleHttpConnectionManager)httpClient.getHttpConnectionManager()).shutdown(); } return resultJson; }