尝试在Linux（RHEL）上打开多个输入流（在单独的线程中）时，我遇到了一个奇怪的问题 . 该行为在Windows上按预期工作 .
我正在开始3个线程打开到3个不同服务器的https连接 . 这三个都是无效的IP地址（在这个测试用例中），所以我希望每个IP地址都有一个NoRouteToHostException . 前两个按预期返回这些，并且很快 . （请参阅下面的堆栈跟踪）然而第三个（当我以这种方式测试时，第四个）不会给出无路由异常 . 它们等待很久，然后给出一个SocketTimeoutException（参见下面的其他堆栈跟踪） . 这需要很长时间才能回来，并且不能准确地表达连接问题 .
令人讨厌的代码行是：
reader = new BufferedReader(new InputStreamReader(conn.getInputStream()));
以前有人见过这样的东西吗？ REHL上的套接字是否存在多线程问题，或者某些地方有多少线程可以同时连接多少？或者......某些东西？
预期的堆栈跟踪，如前两个：
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
第3次收到意外的堆栈跟踪：
java.net.SocketTimeoutException: connect timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:559)
at sun.net.NetworkClient.doConnect(NetworkClient.java:158)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:272)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:916)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1177)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
3 回答
如果无效的IP地址被黑洞化，那么将不会返回任何响应，并且您将获得超时而不是“无路由到主机” . 后者依赖于从网络接收的ICMP错误消息 .
啊 . 现在看，我觉得很傻 . 从上面的回答提示我决定只将IP地址放入浏览器，看看发生了什么 . 事实证明我使用的是以下IP地址：1.1.1.1 2.2.2.2 3.3.3.3
不幸的是，3.3.3.3是一个有效的IP地址，没有响应 . 所以事实上它一直很好 .
我现在使用适当的不可路由的IP地址10.27.1.1等 .
linux防火墙是否会阻止连接？如果填充
iptables -L的输出可能包含您的答案 . 您还可以使用telnet localhost <portnumber>进行测试，以检查端口是否可用 . 如果是，telnet应该说"connected"等 .