HTTP协议无EOF标识时，HttpURLConnection的readLine循环为何不会阻塞？

你通过HttpURLConnection.getInputStream()拿到的并不是原生TCP Socket对应的输入流，是JDK内部按照HTTP协议规范封装后的边界可控流，因此不会出现原生TCP流未收到EOF就持续阻塞的问题，具体逻辑如下：

1. HTTP协议本身定义了明确的响应体终止规则 #

HTTP协议不需要依赖TCP连接关闭来判定响应结束，内置了两种标准终止判定逻辑：

• 带Content-Length响应头：如果响应头中明确标注了响应体的字节长度，上层流会累计已读取的字节数，当读取总量等于Content-Length指定值时，直接返回EOF标记（read()返回-1、readLine()返回null），不会再尝试从底层Socket读取数据。
• 带Transfer-Encoding: chunked分块传输标识：如果服务端没有提前计算好响应体总长度，会采用分块传输格式，每个分块开头会标注当前分块的字节长度，当读到长度为0的结束分块时，就判定响应体读取完成，返回EOF标记。

2. JDK内置实现封装了上述判定逻辑 #

OpenJDK中HttpURLConnection的默认实现返回的输入流是HttpInputStream子类，内部已经内置了上述两种判定逻辑：

• 流初始化时会先解析响应头，确定当前响应采用的终止判定规则
• 每次读取操作都会更新已读计数/解析分块标记，到达终止边界时直接返回结束标识，不会触发底层Socket的阻塞读操作

3. TCP连接复用逻辑与上层流隔离 #

你提到的底层TCP连接不主动关闭是HTTP keep-alive的性能优化：当响应体读取完成后，底层TCP连接会被放回连接池，供同一域名的后续请求复用。但这个逻辑完全在HTTP协议层处理，对上层暴露的输入流已经被标记为结束状态，上层不可能读取到其他请求的响应数据，因此不会出现阻塞。

内容的提问来源于stack exchange，提问作者Zheng Liu