基于com.sun.net.HttpServer的Java服务器内存泄漏排查与修复咨询

结合你提供的代码和现象（Docker中内存每秒涨几MB、手动GC能缓解、HashMap线程休眠仍泄漏），我帮你梳理几个核心问题和对应的修复方法：

1. 最致命的疏漏：HttpExchange资源未完全释放 #

你的MedatadaHandler.handle()方法只关闭了响应的OutputStream，但没有调用HttpExchange.close()！这是com.sun.net.HttpServer的高频坑——HttpExchange对象承载了请求/响应的底层连接、缓冲区等资源，必须在处理完请求后手动调用close()来释放。如果不做这一步，这些资源会被JVM持续持有，每秒一次的请求积累下来，内存必然持续上涨。

修复代码： #

@Override
public void handle(HttpExchange he) throws IOException {
    String response = requestEvents();
    he.sendResponseHeaders(200, response.length());
    OutputStream os = he.getResponseBody();
    os.write(response.toString().getBytes());
    os.close();
    // 必须加这行：释放HttpExchange的所有关联资源
    he.close();
}

2. 日志记录引发的内存堆积 #

你在requestEvents()里每次都用logger.info(jsonString)打印完整的JSON字符串，如果这个JSON体积很大，加上java.util.logging（JUL）的默认行为，很容易导致内存泄漏：

• JUL的默认Handler可能会缓存日志记录，直到缓冲区满才写入文件，大量大体积JSON会占满缓冲区
• 日志事件本身会持有JSON字符串的引用，导致GC无法及时回收这些大对象

修复建议： #

• 修改日志配置，让FileHandler及时刷新缓冲区：在logging.properties里添加java.util.logging.FileHandler.flush=true，并调小bufferSize
• 别打印完整的大JSON，只输出关键元数据（比如事件数量、请求ID）：

// 替换原来的logger.info(jsonString)
logger.info("Processed request, returned " + eventCount + " events");

3. JSON生成的临时对象过载 #

如果requestEvents()里是手动拼接JSON字符串，会生成大量临时String对象，这些对象虽然是短期的，但每秒一次的请求会让GC压力剧增，在Docker环境下可能因为GC触发不及时，看起来像内存泄漏。另外，如果生成的JSON对象被隐式引用（比如未关闭的HttpExchange）持有，也会无法回收。

修复建议： #

• 改用Jackson或Gson这类高效JSON库序列化对象，减少临时字符串生成
• 检查requestEvents()里是否有不必要的对象引用，确保生成的JSON字符串在返回后没有被长期对象持有

4. Docker环境的GC适配问题 #

Docker容器里运行Java应用时，默认GC参数可能没适配容器的内存限制，导致GC触发不及时，手动调用System.gc()能缓解就是这个原因——不是真的泄漏，是GC没来得及干活。

修复建议： #

• 给Java进程设置适配容器的GC参数，比如：

java -Xmx512m -Xms256m -XX:+UseG1GC -XX:+UseContainerSupport -jar your-server.jar

• 别依赖手动调用System.gc()，这会干扰JVM的自动GC调度，让内存管理更混乱

先优先修复HttpExchange.close()这个问题，这大概率是核心原因。如果还有内存增长，用VisualVM或JProfiler dump堆内存，看哪些对象占比最高，就能精准定位剩余问题了。

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