oracle aq消费不能直接jdbc，必须使用oracle官方jms实现（aqapi.jar+ojdbc8.jar），通过aqjmsconnectionfactory创建连接，并用aqjmssession配合messagelistener实现异步安全消费。
Oracle AQ 消费必须用 JMS 还是能直接 JDBC？
不能直接 JDBC。Oracle 高级队列（AQ）底层依赖 PL/SQL 包 DBMS_AQ 和队列表结构，JDBC 无法安全、原子地完成出队（dequeue）+ 确认（commit）+ 异常回滚这一整套语义。官方唯一支持的异步消费路径是 Oracle 提供的 JMS 实现——oracle.jms.AQjmsSession，它封装了底层 AQ 操作，并支持 MessageListener 回调。
常见错误现象：有人试图用 CallableStatement 调 DBMS_AQ.DEQUEUE 并设 WAIT => DBMS_AQ.NOWAIT 轮询，结果出现消息重复消费、状态不一致或 ORA-25228（超时或无消息）频繁抛异常——这不是异步，是伪异步 + 高开销轮询。
- 必须使用 Oracle 官方 JMS provider（
aqapi.jar+ojdbc8.jar） - 连接工厂必须是
oracle.jms.AQjmsConnectionFactory，不是通用ConnectionFactory - 队列名需带 schema 前缀，如
"SCOTT.MY_QUEUE"，否则AQjmsSession.createQueue()会报 ORA-00942
如何配置非阻塞监听器而不卡线程？
关键在 setDeliveryMode(DeliveryMode.NON_PERSISTENT) 和 setMessageListener() 的组合，但仅这样还不够——Oracle JMS 的非阻塞本质靠的是内部线程池驱动 dequeue，而非 NIO。若未显式配置，它默认使用单线程同步拉取，仍会阻塞。
实操要点：
- 调用
connection.start()前，必须先设置connection.setClientID("my-client")，否则createDurableSubscriber或 listener 注册会失败 - 监听器内禁止做耗时操作（如 HTTP 调用、文件写入），否则线程池被占满后新消息积压，AQ 表中
MSG_STATE = 'READY'消息数持续上涨 - 推荐在 listener 中只做轻量解析 + 投递到本地
ExecutorService，例如：executor.submit(() -> process(msg));
- 务必捕获
JMSException并记录，否则异常会静默终止 listener，后续消息不再到达
为什么 setWaitTime(0) 不等于“立即返回”？
Oracle AQ JMS 的 setWaitTime(0) 行为和预期相反：它不会立即返回空，而是触发“短轮询+休眠”策略，实际延迟约 100–500ms，且仍占用一个 listener 线程。真正零等待、零线程占用的方式是启用 MessageListener + 后台 dequeue 线程由 Oracle 内部管理——此时 wait time 应设为 UNLIMITED 或合理值（如 30），让 Oracle 控制节奏。
性能影响明显：实测 setWaitTime(0) 下每秒吞吐不足 50 条；改为 setWaitTime(30) + 正确 listener 后可达 300+ 条/秒（取决于 DB 负载和网络）。
- 不要在 consumer 上手动调
receiveNoWait()，那是同步阻塞模型残留接口 - 如果业务要求“秒级可见”，检查 AQ 队列表的
RETENTION和EXPIRY参数是否过短，导致消息未被消费就转入EXPIRED状态 - 监控视图用
USER_QUEUE_VIEW查WAITING_MSGS，而非只看DBA_QUEUE_SCHEDULES
事务边界怎么划才不丢消息也不重复？
Oracle AQ JMS 默认开启 session 事务（session = connection.createSession(true, Session.SESSION_TRANSACTED)），但这是双刃剑：commit 成功前消息始终处于 PROCESSED 状态，数据库 crash 可能导致消息丢失；而 rollback 又可能引发重复投递（因 dequeue 已发生）。
更稳的做法是关闭 session 事务，改用 autoAcknowledge 模式 + 手动控制 DB 事务：
- 创建 session 时用
connection.createSession(false, Session.AUTO_ACKNOWLEDGE) - 在
MessageListener.onMessage()内，先完成业务逻辑（含 DB 更新），再显式调用msg.acknowledge() - 若业务 DB 操作失败，不调 acknowledge，消息保留在队列中（状态变回
READY），下次重试 - 注意：
acknowledge()必须在同一线程、同一 session 中调用，跨线程会导致 ORA-25230
最容易被忽略的一点：Oracle AQ 的 message ID（JMSMessageID）在 enqueue 时生成，但 dequeue 后若未 acknowledge，该 ID 不会复用——所以用它做幂等键是安全的；但若用了自定义属性做去重，要确认 producer 是否设置了 setJMSReplyTo() 或其它干扰字段。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
