FAN不生效的根本原因是客户端未启用oracle.jdbc.fanEnabled=true且服务端未通过srvctl modify service -e SERVICE_RESTART启用FAN事件，二者缺一不可。
为什么 FAN 不生效，连接池还在往宕机节点发请求？
这事儿其实挺常见，根源往往就出在两个地方：要么是JDBC连接串里压根没打开FAN开关，要么是Oracle RAC那边压根没给服务开启FAN支持。你得明白，FAN是个双向机制，就像对讲机：数据库这边得能发出“节点挂了”的事件广播，JDBC驱动那边得能接收并做出反应。光把客户端配置好，数据库那头没动静，等于白忙活。
- 关键参数
oracle.jdbc.fanEnabled=true必须明确地加在连接URL或者Properties里，它的默认值可是false，不会自动生效。 - 对应的数据库服务（
service_name）必须在RAC集群上使用命令srvctl modify service -f ... -e SERVICE_RESTART -m BASIC -z 1来启用FAN事件。这里面的-e SERVICE_RESTART是灵魂所在，没它不行。 - 务必使用
OracleDataSource来获取连接，老式的DriverManager.getConnection()方法根本不支持注册FAN回调。 - 最后，还得确认数据库版本至少是11.2，并且监听器在
listener.ora文件里针对USE_DEDICATED_SERVER配置了ENABLE=ON。早期的监听器版本可能会默默地丢弃FAN数据包，导致事件石沉大海。
OracleConnectionPoolDataSource 怎么配合 FAN 做连接清理？
这里有个常见的误解：以为FAN能自动关闭坏连接。其实不然，FAN只负责通知“某个节点不可用了”，至于清理池子里那些指向该节点的无效连接，这个动作得由连接池自己来触发。像HikariCP、UCP这些主流连接池，它们通过监听特定适配器的事件来间接响应FAN。但如果你用的是原生的 OracleConnectionPoolDataSource，就需要手动做一些集成工作。
- 必须调用
setFastConnectionFailoverEnabled(true)。这是开关，没打开的话，就算收到了FAN事件，池子也不会触发失效检查。 - 设置了
setConnectionPoolName("my_pool")之后，别忘了在应用启动时，通过代码获取连接池管理器并设置非活跃连接超时。这能让池子定期清理那些卡在宕机节点上的“僵尸”连接。 - 别指望
setTimeToLiveConnectionTimeout()能解决这个问题——它只管空闲连接的存活时间，对于已经借出去、但目标节点突然挂掉的连接，它无能为力。 - 一个参考的连接串示例：
jdbc:oracle:thin:@//rac-scan:1521/my_service?oracle.jdbc.fanEnabled=true&oracle.net.disableOob=true。加上disableOob参数有时能避免FAN的UDP包被某些网络设备误拦截。
连接池返回 SQLException: IO Error: Connection reset 还继续重试？
这是典型的FAN通知延迟或覆盖不到的场景。想象一下：数据库节点刚刚宕机，FAN事件还在路上，没传到客户端呢，连接池就已经把一个旧的、指向该节点的连接借给了应用线程。等这个连接去执行SQL时，TCP层直接断连，抛出“Connection reset”错误。这时候，不能干等FAN，必须依靠连接验证机制来兜底。
- 所有连接池都必须开启连接测试查询（
connection-test-query）或等效机制，比如HikariCP可以设成SELECT 1 FROM DUAL，并且要把test-on-borrow设为true（或者在借出前验证）。 - Oracle官方更推荐使用
isValid(2)方法来替代SQL查询，这样更轻量，但前提是驱动版本要在12.1以上。老版本驱动就只能用查询了。 - 验证超时时间（
validation-timeout）别设得太长，建议不超过3秒，否则验证操作本身就会拖慢业务线程。 - 需要明确一点：FAN通知的是“服务不可用”这个事件，而不是“某个具体连接已断开”。所以，连接验证逻辑和FAN事件通知是两层不同的防御机制，相辅相成，缺一不可。
为什么 UCP 池里看到 getA vailableConnectionsCount() 没变，但实际请求全失败？
这是因为UCP（Universal Connection Pool）默认不会主动去探测连接的有效性。getA vailableConnectionsCount() 这个方法，只是简单地统计“当前没被借出去”的连接数量，至于这些连接背后是否还链接着一个活着的数据库节点，它并不关心。当FAN事件到达后，UCP会把对应的物理连接标记为“stale”（陈旧的），但不会立即将它们从池子里物理移除，除非这个连接被借出时验证失败，或者达到了某种超时限制。
- 你可以调用
getConnectionPool().purgeStaleConnections()来强制清理这些陈旧连接。但注意，这个方法会锁住连接池，影响并发性能，所以别一收到FAN事件就不分青红皂白地调用。 - 更稳妥的做法是设置
setAbandonedConnectionTimeout(60)，让UCP自动去回收那些被借出后长时间未归还、且状态可疑的连接。 - 监控的重点不应该只是“可用连接数”。更应该关注
getFailedBorrowCount()（借出失败计数）和getInvalidConnectionCount()（无效连接计数），这两个指标如果突然飙升，才真正说明“FAN事件接收+连接清理”这个链路出了问题。 - 别忘了查看日志。打开
oracle.ucp.level=FINEST级别的日志，然后搜索FAN_EVENT_RECEIVED和INVALIDATE_CONNECTION这类关键字，能帮你确认FAN事件是否真的被接收并处理了。
说到底，FAN不是那种打开开关就万事大吉的“魔法”。它是数据库、网络、驱动、连接池四层协同工作的结果。实践中，最容易漏掉的两步恰恰是最关键的：一是服务端忘记用 srvctl modify service 命令启用事件；二是客户端漏设了 fastConnectionFailoverEnabled 属性。这两步缺了任何一步，其他所有配置都等于白费功夫。
