HttpURLConnection请求受限二维码URL时持续加载的问题排查与解决

一、持续加载的根本原因 #

• HttpURLConnection默认没有设置连接超时和读取超时，当目标URL被服务器限制（比如防火墙拦截、对方服务器不响应TCP连接、或连接后不返回数据）时，getResponseCode()方法会一直阻塞等待，不会主动抛出异常，这是生产环境出现无限加载的核心原因。
• 本地测试的受限URL可能直接返回错误码（如403、404），或是本地网络的系统级TCP超时触发了异常，但生产环境的网络/防火墙规则可能让连接处于挂起状态，未触发系统级超时，导致代码持续卡住。

二、代码处理方式与修复 #

必须给HttpURLConnection设置连接超时和读取超时，同时优化异常处理逻辑，确保所有阻塞操作都有时间限制：

修改后的代码 #

try {
    URL url = new URL(constructedUrl);
    HttpURLConnection connection = (HttpURLConnection) url.openConnection();
    connection.setRequestProperty("User-Agent", "Mozilla/5.0");
    
    // 设置超时时间（单位：毫秒），可根据业务场景调整，例如5秒连接超时、10秒读取超时
    connection.setConnectTimeout(5000);
    connection.setReadTimeout(10000);
    
    int responseCode = connection.getResponseCode();
    if (responseCode == HttpURLConnection.HTTP_OK) {
        // 用try-with-resources自动关闭输入流，避免资源泄漏
        try (InputStream inputStream = connection.getInputStream()) { 
            // 加载图片
            BufferedImage originalImage = ImageIO.read(inputStream);

            // 将图片写入本地服务器的逻辑
        }
    } else {
        exceptionOccurred = true;
        log.log(Level.SEVERE, "生成二维码时连接失败，响应码: " + responseCode);
    }
} catch (MalformedURLException e) {
    exceptionOccurred = true;
    log.log(Level.SEVERE, "生成二维码时出现URL格式错误");
    e.printStackTrace();
} catch (SocketTimeoutException e) { // 单独捕获超时异常，便于精准排查
    exceptionOccurred = true;
    log.log(Level.SEVERE, "生成二维码时请求超时（连接或读取超时）");
    e.printStackTrace();
} catch (IOException e) {
    exceptionOccurred = true;
    log.log(Level.SEVERE, "生成二维码时出现IO异常");
    e.printStackTrace();
} catch (Exception e) {
    exceptionOccurred = true;
    log.log(Level.SEVERE, "生成二维码时出现未知异常");
    e.printStackTrace();
}

关键优化点 #

• 添加setConnectTimeout：限制建立TCP连接的最长等待时间，超时后抛出SocketTimeoutException
• 添加setReadTimeout：限制从输入流读取数据的最长等待时间，超时后抛出SocketTimeoutException
• 使用try-with-resources自动关闭InputStream，替代手动finally关闭，避免资源泄漏
• 单独捕获SocketTimeoutException，精准定位超时类问题，方便日志排查
• 提前获取并存储responseCode，避免重复调用getResponseCode()，逻辑更清晰

三、是否需要设置超时？ #

必须设置。生产环境网络环境复杂（防火墙、代理、目标服务器不稳定等），无超时限制的网络请求极易导致线程挂起，最终耗尽应用线程池，引发服务雪崩，即使本地测试正常也不能省略。

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