ORA-12170超时90%非数据库问题，而是DNS解析阻塞、JDBC驱动注册异常、RAC跨节点通信或JDK GC策略不匹配所致，需分别从nslookup测试、删除Class.forName、检查v$session、调整G1参数等入手排查。

ORA-12170超时90%不是数据库问题，而是DNS卡在解析环节

Ja va应用连接Oracle慢，报出ORA-12170: TNS:connect timeout occurred，先别急着去查监听或者防火墙。这个错误在Ja va环境里，很大程度上并不反映数据库的真实状态，它更像是一个信号，暴露了JDBC Thin驱动在建立TCP连接之前，就已经卡在了“名字解析”这个环节上。关键在于，它不读取sqlnet.ora文件，也不走系统的/etc/hosts，完全依赖于JVM自身的InetAddress.getByName()行为。

遇到这种情况，可以按以下步骤来操作：

• 先用nslookup your-oracle-host测试一下DNS响应时间，如果超过1秒，风险就很大了；此时换成IP地址直连，如果瞬间连通，那问题基本就锁定了。
• 在Ja va进程启动时，加上JVM参数：-Dsun.net.inetaddr.ttl=30 -Dsun.net.inetaddr.negative.ttl=30，目的是避免JVM缓存那些失败的解析结果。
• 尽量不要在连接URL里写主机名，直接改用IP地址：jdbc:oracle:thin:@//192.168.10.5:1521/ORCLPDB1（注意双斜杠//和末尾的/service_name格式）。
• 如果业务上必须使用域名，而DNS又不可控，可以在应用启动前，通过代码InetAddress.getByName("your-oracle-host");执行一次预热解析。

ojdbc11.jar加载后没注册驱动？删掉Class.forName()就行

在Ja va 11及以上的项目中，手动调用Class.forName("oracle.jdbc.driver.OracleDriver")不仅多余，还可能在模块化环境（JPMS）下引发IllegalAccessError。实际上，ojdbc11.jar包通过META-INF/services/ja va.sql.Driver机制已经实现了驱动的自动注册，遗留的旧代码反而会干扰这个过程。

可以这样处理：

• 彻底清理代码中所有Class.forName(...)的调用，包括配置类、工具类，甚至是测试代码里的显式加载。
• 验证驱动是否生效：可以在运行时打印DriverManager.getDrivers()，输出列表里应该包含oracle.jdbc.OracleDriver@xxx（注意，是新类名oracle.jdbc.OracleDriver，而不是旧的oracle.jdbc.driver.OracleDriver）。
• 如果需要动态切换驱动（比如多数据源场景），必须使用新的类名：Class.forName("oracle.jdbc.OracleDriver")，旧类名在ojdbc11里只是一个空壳。
• 检查jar包来源：建议从Ma ven中央仓库拉取com.oracle.database.jdbc:ojdbc11:23.5.0.23.09这样的正式版本，避免使用网上一些来路不明的“免安装版”，缺少签名可能会抛出SecurityException。

GC等待高导致连接池获取连接变慢？先看是不是RAC跨节点访问

如果连接池（比如HikariCP）的日志显示Connection acquisition timed out，同时数据库AWR报告里出现了大量的gc buffer busy acquire或gc cr block busy等待事件，那么问题很可能不在JDBC这一层，而在于Oracle RAC实例间的Cache Fusion通信压力。Ja va线程卡在等待获取连接，本质上是数据库内部节点间数据同步延迟，传导到了应用层。

立即学习“Ja va免费学习笔记（深入）”；

排查和解决思路如下：

• 首先确认应用会话是否被调度到了非主节点：查询v$session视图的inst_id字段，对比业务表的主分区所在实例。
• 临时规避方案：可以在JDBC连接URL后面加上参数?oracle.jdbc.useDefaultRowPrefetch=false，这有助于减少单次数据抓取（fetch）带来的跨节点数据块请求。
• 长期优化方案：调整应用的路由策略，让同一批次的相关任务尽量落在同一个RAC节点上；或者对高频访问的表启用ALTER TABLE ... PARALLEL，并结合服务名（Service）进行绑定。
• 切记不要盲目调大连接池的maxPoolSize——这只会加剧数据库内部的GC争用，反而拖慢整体吞吐量。

JDK 11默认G1 GC对Oracle长事务有隐性影响

JDK 11开始默认使用G1垃圾收集器，而G1的并发标记周期（Concurrent Cycle）可能与Oracle长事务的UNDO段扩展产生冲突。典型的现象是连接能建立，但在执行SELECT ... FOR UPDATE或批量INSERT时，Ja va线程会在ja va.net.SocketInputStream.socketRead0处长时间阻塞，同时数据库侧会出现enq: TX - row lock contention等待事件上升。

针对此问题的建议：

• 对于OLTP类型的Oracle应用，可以在启动JVM时显式指定GC算法：-XX:+UseParallelGC（尤其是在内存8G以下的机器上）。
• 如果坚持使用G1，可以添加参数-XX:MaxGCPauseMillis=200，并密切监控GC日志中Concurrent Cycle的发生频率，尽量避免其与数据库锁竞争的高峰时段重叠。
• 检查JDBC URL是否遗漏了tcpKeepAlive=true参数，这可以防止网络中间设备（如NAT网关）静默断开连接后，Ja va端未能及时感知，导致重试逻辑卡在socket read上。
• 确保连接池启用了类似connection-test-query=SELECT 1 FROM DUAL和validation-timeout=3000的配置，以便快速剔除那些因GC停顿时间过长而失效的连接。

总的来说，Ja va连接Oracle慢的真实原因，常常隐藏在JVM底层行为和Oracle RAC内部机制的交互地带，而不是驱动版本或URL格式这类表层问题。DNS解析、驱动自动注册、GC策略、RAC节点亲和性——这四个关键点，任意一个没对齐，都可能让一次简单的数据库连接变成耗时耗力的排查攻坚战。