Docker中Spring Boot执行带时间条件JDBC查询时容器异常退出

首先注意核心异常信号：你代码里写的SQL时间条件时区是-0700，但最后日志打印的实际执行SQL里时区变成了-0300，说明时区参数在JDBC驱动层被自动改写了，容器直接终止删除不是SQL语法错误导致的——语法错误只会抛出Java层的SQL异常，不会直接杀死整个进程。

容器直接退出且无应用层错误栈，本质是JDBC驱动在解析带微秒+显式时区偏移的timestamp字面量时触发了底层崩溃，直接把JVM主进程杀死了：

• 如果你启动容器时加了--rm参数，容器主进程（JVM）退出后会被Docker自动删除，就会出现你看到的“直接终止并被删除”的现象。
• 这类崩溃通常是两种情况触发：要么是老版本JDBC驱动（尤其是带JNI native实现的时序数据库驱动，比如旧版TDengine、ClickHouse、TimescaleDB驱动）解析该格式时间值时出现内存越界，触发操作系统SIGSEGV段错误直接杀进程；要么是驱动自动做时区转换后，查询的时间范围被错误放大，扫描了超量数据触发容器内存OOM，被cgroup直接杀死进程，两种情况都不会留下Java层的异常日志。
• 其余查询正常，是因为其他SQL没有走到驱动里这段处理带时区高精度时间戳的bug逻辑分支。

• 先查容器退出码定位具体崩溃原因：执行docker inspect <你的异常退出容器ID> | grep ExitCode，返回139对应段错误（驱动native层崩溃），返回137对应OOM被系统杀死。
• 禁止在SQL里硬拼接带时区的时间字符串，改用JDBC预编译占位符传参：把时间条件改成timestamp >= ? AND timestamp <= ?，通过OffsetDateTime类型的Java对象传入时间参数，从根源上避免驱动解析字符串字面量的bug，也不会出现时区值被自动改写的问题。
• 升级当前使用的JDBC驱动到最新稳定版，这类时间解析触发进程崩溃的bug基本都在各驱动的新版本中被修复。
• 统一时区配置：JVM启动参数加-Duser.timezone=UTC固定JVM时区，同时确保JDBC连接参数配置的时区、数据库服务端时区保持一致，避免驱动自动做时区转换时出现逻辑错误。
• 临时验证可以先去掉SQL里时间值的时区后缀，传入UTC时区的时间字面量执行，如果查询正常返回，即可确认是时区解析环节触发的问题。

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