max-wait 过大会导致 spring boot 启动卡顿，因为连接池耗尽时线程会阻塞等待指定毫秒数（如30000即30秒），而启动初期 redistemplate 初始化等操作并发争抢连接，造成容器刷新阶段假死。
Spring Boot 应用启动时卡在 Redis 连接阶段，常见原因是连接池配置不当导致线程阻塞等待，而非 Redis 服务本身不可达。
为什么 max-wait 配置过大会让 Spring Boot 启动变慢
Spring Boot 默认使用 Lettuce 客户端（2.x 起），其连接池依赖 commons-pool2。当连接池中无可用连接、且所有连接都在使用中时，新获取连接的请求会阻塞在 max-wait 设置的时间内，直到超时或获得连接。
若该值设为几秒甚至几十秒（如 max-wait: 30000），而应用启动初期大量 Bean（如 RedisTemplate 初始化、缓存预热、健康检查）并发申请连接，就会集体卡住——表现就是整个应用“假死”数秒才继续启动。
-
max-wait是毫秒单位，不是秒；设成30000就是等 30 秒 - 这个等待发生在 Spring 容器刷新阶段，早于业务逻辑，所以日志里常看不到明显报错，只看到启动耗时突增
- 即使 Redis 实例正常，只要连接池已满且
max-wait过长，照样卡住
如何验证是否是 max-wait 导致的阻塞
打开 application.yml 或 application.properties，检查是否有显式配置了过大的 max-wait 值；同时确认 max-active 是否偏低（默认通常为 8），导致连接快速耗尽。
- 查看连接池配置项：
spring.redis.lettuce.pool.max-wait、spring.redis.lettuce.pool.max-active - 启动时加 JVM 参数
-Dio.lettuce.core.tracing=DEBUG可观察 Lettuce 连接获取行为（需启用 debug 日志） - 用
jstack <pid></pid>抓线程栈，搜索org.apache.commons.pool2.impl.GenericObjectPool.borrowObject，若大量线程停在此处，基本可断定是连接池阻塞
推荐的连接池参数组合（Lettuce + Spring Boot 2.7+）
不追求最大吞吐，而是平衡启动速度与运行时稳定性。以下数值适用于中小流量应用（QPS
-
max-active: 16—— 避免默认 8 不够用，又不至于过度占用 Redis 连接数 -
max-idle: 16—— 与max-active保持一致，减少动态扩缩容开销 -
min-idle: 4—— 预热基础连接，避免冷启动首次请求延迟 -
max-wait: 2000—— 2 秒是合理上限；超过即应失败，而非无限等待 - 务必配
time-between-eviction-runs: 30000和min-evictable-idle-time-millis: 60000，防止空闲连接僵死
示例配置：
spring:
redis:
lettuce:
pool:
max-active: 16
max-idle: 16
min-idle: 4
max-wait: 2000
time-between-eviction-runs: 30000
min-evictable-idle-time-millis: 60000
更隐蔽的坑：健康检查触发过早
Spring Boot Actuator 的 redis 健康检查默认在应用上下文刷新完成前就执行，它会主动尝试获取一个连接做 PING。如果此时连接池还没初始化好、或被其他 Bean 占满，它也会陷入 max-wait 等待，进一步拖慢启动。
- 临时禁用：设置
management.endpoint.health.show-details: never或management.health.redis.enabled: false - 更稳妥做法：把健康检查延后，例如通过
@DependsOn("redisConnectionFactory")显式控制顺序 - 注意：Lettuce 的
ping是同步阻塞调用，不像 Jedis 可设超时，所以健康检查失败也可能卡住
真正难排查的，往往不是连接连不上，而是连接“能连上但拿不到”。max-wait 这个参数太安静，不出错也不报警，只默默拖慢一切。
