问题描述

某系统接连出现连接泄漏问题。表现为：

1. 使用 RabbitMQ 作为消息队列，使用 RabbitMQ 的 Connection 进行消息发送。
2. 封装了 RabbitMQ 客户端，使用 ThreadLocal 保存 Connection。

连接数持续增长，直到连接达到 RabbitMQ 的最大连接数，导致系统无法正常工作。

分析

此问题出现周期间隔较长，且每次出现时，系统日志中均无异常信息，无法通过日志分析问题。只有最终的连接泄漏报错处，打出了少量的日志信息。

一开始出现时，怀疑是网络问题，导致无法连接。但排查后，发现网络一切正常。

直至后来某次，日志明确报出：The channelMax limit is reached，才意识到是连接泄漏问题。

检索代码，发现 ThreadLocal 的使用方式如下：

issue url

• github url
• gitee url

版本情况

hutool版本： 5

问题描述（包括截图）

参考文档构建代码：AIO封装-AioServer和AioClient
其中 AioClient 的示例如下：

public void foobar() {
    AioClient client = new AioClient(new InetSocketAddress("localhost", 8899), new SimpleIoAction() {
        
        @Override
        public void doAction(AioSession session, ByteBuffer data) {
            if(data.hasRemaining()) {
                Console.log(StrUtil.utf8Str(data));
                session.read();
            }
            Console.log("OK");
        }
    });
    
    client.write(ByteBuffer.wrap("Hello".getBytes()));
    client.read();
    
    client.close();
}

若直接在生产环境调用此代码，将必然出现线程溢出 OOM

issue url

issue: druid issue #5414

现象

发生系统无法响应情况

分析

观察 javacore 及 log4j2.xml 配置，发现存在通过日志直接插数据库配置。

convert tools

读码心得

近期碰到 netty 报 io.netty.util.internal.OutOfDirectMemoryError 错误，排查发现是 netty 最大非堆内存大小限制导致的。

问题

当前工作中，我们使用 Maven 构建 Java 项目，但是未采用 Maven 最佳实践滚动更新版本，反复使用同一版本号。这导致了版本信息丢失，无法追溯到具体的版本。

带来的问题：

1. 无法在具体版本上进行问题修复，每次都需要更新到最新后进行修复，修复风险人为变大
2. 查找问题时无法快速定位到具体版本，处理故障的时间在定位版本上就要花费大量时间

问题

工作中，C/C++ 编译出的程序在无要求下，不会携带版本信息。无版本信息下，定位问题时，会非常麻烦。
CICD 可注入版本信息，但对项目有一定侵入性，项目组较抵触。

对比测试

对目前可获得的几种对象池进行性能测试，测试场景如下：

• 一取一放场景
• 多取多放场景

工作上需要一个对象池，目的是在高并发下减少 GC 对总体的影响。外部也没看到相关的实现。所以，决定写一个。

工作中有项目使用 jfx 在 Linux 运行。有需求需要播放音频。