用 HttpURLConnection 发起 GET 请求并判断状态码是否正常
核心就是发一次请求、读取响应码、不抛异常就代表“通”，但很多人卡在连接超时没设或重定向被忽略。
Java 默认会自动跟随 301/302，但监控网页时你通常不希望它跳转后才算“正常”——比如你监控的是登录页，跳到首页反而说明登录态失效了。
实操建议：
- 显式调用
setInstanceFollowRedirects(false)关闭自动重定向 - 必须设置
setConnectTimeout(5000)和setReadTimeout(5000)，否则 DNS 挂掉或服务器假死会让整个监控线程卡住 - 只信任
200 （可按需放宽到 <code>200–399），401、403虽是客户端错误，但页面能返回也算“可达”；而500、502就该告警 - 别只看
getResponseCode()，如果网络不通，它会抛IOException，得用 try-catch 捕获
怎么处理 HTTPS 网站的证书问题（如自签名、过期）
监控内网系统时经常遇到自签名证书，HttpURLConnection 默认拒绝，直接报 javax.net.ssl.SSLHandshakeException。
不能直接信任所有证书（安全红线），但可以针对特定域名临时绕过验证，仅用于监控场景：
实操建议：
- 写一个轻量
TrustManager，只对目标域名（如intranet.example.com）放行，其他仍走默认校验 - 用
HttpsURLConnection.setDefaultSSLSocketFactory(...)注入，注意这是 JVM 级别设置，多监控任务共用时要小心污染 - 更稳妥的做法：把自签名证书导出为
.crt，用keytool -importcert加入 JRE 的cacerts，一劳永逸
为什么 getResponseMessage() 总是 null，该怎么获取真实响应内容
getResponseMessage() 只返回 HTTP 状态行里的短语（如 “OK”、“Not Found”），不是响应体；而监控时你常需要检查 HTML 里有没有 “Maintenance” 字样或某个关键元素是否存在。
实操建议：
- 用
getInputStream()读响应体（注意：只有响应码 ≥ 200 且 getErrorStream()） - 别用
Scanner或BufferedReader.readLine()直接读，容易因编码问题乱码；优先用new String(bytes, StandardCharsets.UTF_8) - 如果只查关键词，用
InputStream+StreamTokenizer或正则匹配前 10KB 就够，避免加载整页大 HTML 吃内存 - 记得关流：
try-with-resources包住InputStream，否则连接不释放会耗尽 socket
定时轮询多个 URL 时，怎么避免线程堆积和连接泄漏
用 TimerTask 或 ScheduledExecutorService 跑周期任务很常见，但每次新建 HttpURLConnection 不关连接、不复用，几分钟后就会触发 java.net.SocketException: Too many open files。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 每个监控任务用独立的
ExecutorService线程池（如Executors.newSingleThreadScheduledExecutor()），别全塞进一个大池子 - 必须显式调用
disconnect()，虽然文档说“不是必须”，但在高频率轮询下不调它，连接可能滞留在CLOSE_WAIT状态 - 加个简单计数器：每 10 次请求打一行日志，记录耗时、状态码、是否重定向，方便定位是网络抖动还是目标服务退化
- 别在监控逻辑里做复杂解析（如 Jsoup 渲染 DOM），纯文本匹配就够了；真要 JS 渲染，换 Puppeteer，别硬扛
最易被忽略的是连接超时和重定向控制——它们不报错，但会让你误判“服务正常”，其实只是跳到了错误页面或卡在 DNS 查询上。
