CRS.decode执行陷入死锁无响应，求助排查方案（GeoTools 26.5）

• EPSG数据集依赖缺失：gt-referencing本身不包含EPSG坐标参考系统的数据集，若未引入gt-epsg-hsql或gt-epsg-sqlite等数据模块，程序会尝试远程加载EPSG数据或陷入初始化阻塞。
• 本地EPSG数据库异常：使用嵌入式EPSG数据库时，若数据库文件缺失、权限不足（程序无读写权限）或文件损坏，会导致加载过程停滞。
• 线程死锁：初始化CRS模块时，若当前线程与其他业务线程持有互相等待的锁，会引发死锁，表现为程序无响应。
• 网络阻塞（若配置远程数据源）：若手动修改配置让GeoTools从远程拉取EPSG数据，网络不通、超时未触发异常时会导致停滞。
• 依赖冲突：项目中存在不同版本的GeoTools模块（如gt-*）或其依赖库（如HSQLDB、SQLite-JDBC），可能引发类加载阻塞或初始化死锁。

• 检查依赖完整性：确认项目已引入gt-epsg-hsql或gt-epsg-sqlite依赖（与gt-referencing版本保持一致），避免因缺失数据集导致的阻塞。
• 导出线程栈分析：使用jstack <进程ID>命令导出线程栈，查看停滞线程的状态：
  • 若线程处于BLOCKED状态，检查是否存在锁竞争；
  • 若线程停留在EPSG数据库初始化代码段，定位数据库加载异常原因。
• 验证本地EPSG数据库：找到嵌入式数据库文件（如HSQLDB的.db文件），检查文件是否存在、权限是否正常，可尝试删除文件让GeoTools重新生成。
• 强制使用本地数据源：在代码中添加系统属性，强制指定本地EPSG数据源，避免远程加载：

  System.setProperty("org.geotools.referencing.crs.EPSGDataSourceFactory", "org.geotools.referencing.factory.sqlite.SQLiteEPSGDataSourceFactory");
  

• 排查依赖冲突：通过mvn dependency:tree（Maven）或gradle dependencies（Gradle）查看依赖树，移除冲突的第三方库或GeoTools模块，统一版本。
• 最小化测试：编写仅包含CRS.decode("EPSG:4326", true)的测试类，排除业务代码干扰，验证问题是否由GeoTools本身引发。
• 监控系统资源：使用jconsole或jvisualvm查看进程的内存、GC及磁盘IO情况，排查是否因资源不足导致加载停滞。

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