3. 配置参数详解：maxIdleConnections、keepAliveDuration 与 cleanupRunnable 机制

3.1 参数作用与原理

连接池的核心参数控制着空闲连接的生命周期和复用能力。OkHttp 默认连接池 new ConnectionPool() 等价于：

3.2 maxIdleConnections 深度解析

含义：每个“路由”（即 host + port + 协议）在连接池中最多允许保留的空闲连接数量。注意：不是连接池总连接数，而是按路由隔离的配额。

为何按路由隔离？ 不同服务器的连接不能互用。例如同时请求 api.example.com:443 和 cdn.example.com:443，各有独立 maxIdleConnections 限制。

配置建议：

• 短连接高频场景（如 API 网关、微服务调用）： 建议提升至 10~20，减少 TCP 握手开销。
• 长连接低频场景（如网页浏览）： 默认 5 足够。
• 注意： 增大 maxIdleConnections 会占用更多文件描述符，需结合系统 ulimit 调整。

// 创建自定义连接池：每个路由最多保留 10 个空闲连接
ConnectionPool pool = new ConnectionPool(10, 5, TimeUnit.MINUTES);
OkHttpClient client = new OkHttpClient.Builder()
    .connectionPool(pool)
    .build();

3.3 keepAliveDuration 单位与精度

单位： 构造方法中传入 long time, TimeUnit unit，支持任意 TimeUnit（NANOSECONDS 到 DAYS）。内部统一转换为 纳秒 存储。

精度影响： 实际清理定时器使用 System.nanoTime() 差值，精度可达微秒级，但连接复用判断在纳秒级比较。建议使用秒或分钟为单位，避免因纳秒过度精度导致不必要的抖动（但 OkHttp 已内部取整）。

常见误用： 设置 keepAliveDuration = 0 或极小值（如 1 毫秒）会导致连接刚放入池就被清理，完全失去复用效果，等同于禁用连接池。

// 正确示例：保持 10 秒空闲超时
ConnectionPool pool = new ConnectionPool(5, 10, TimeUnit.SECONDS);

// 错误示例：设置过短的超时（实际等于无复用）
ConnectionPool wrongPool = new ConnectionPool(5, 1, TimeUnit.MILLISECONDS);

3.4 cleanupRunnable 工作机制

运行原理： 当连接池中有至少一个空闲连接时，cleanupRunnable 开始执行。它执行以下步骤：

1. 计算当前时间（纳秒）与每个空闲连接最后使用时间的差值。
2. 选出已超过 keepAliveDuration 的连接，标记为待清理。
3. 如果待清理连接数超过 maxIdleConnections，则按“空闲时长从长到短”排序，保留最近的 N 个，移除多余的。
4. 执行清理关闭操作，然后调度下一次清理（默认等待 keepAliveDuration 的一半时间，最小 0.1 秒，最大 60 秒）。

3.5 调试验证方法

通过 ConnectionPool 的 connectionCount() 和 idleConnectionCount() 方法实时监控：

// 自定义监控线程
ScheduledExecutorService monitor = Executors.newScheduledThreadPool(1);
monitor.scheduleAtFixedRate(() -> {
    int total = client.connectionPool().connectionCount();
    int idle = client.connectionPool().idleConnectionCount();
    System.out.printf("[连接池] 总:%d 空闲:%d 活跃:%d%n",
        total, idle, total - idle);
}, 0, 2, TimeUnit.SECONDS);

验证步骤：

1. 使用小型压测工具（如 OkHttp 同步循环请求），观察空闲连接数是否在 maxIdleConnections 附近波动。
2. 设置不同 keepAliveDuration（如 5 秒、30 秒），停止请求后观察空闲连接存活时长与配置是否一致。
3. 通过抓包（tcpdump / Wireshark）确认 FIN 或 RST 发起的时机。

3.6 性能提升数据参考（实测）

测试环境：Android 模拟器 API 30，单个 host:port，同步请求，间隔 200ms。默认 keepAliveDuration=5min 在高频场景下实际不如短超时更灵活。

3.7 内联 SVG：连接池三个参数协同工作流程