Oracle AQ在Java中需三处硬刚：必须用TNS描述符或ldap/wallet配置JNDI，禁用直连；必须用AQjmsXAConnectionFactory保障事务一致性；数据库字符集须为AL32UTF8，否则中文静默乱码。
oracle aq 在 java 应用中不是“开箱即用”的消息中间件，它不提供独立的 broker 进程，也不支持直连式 jndi 或 spring boot 自动配置。想让它在现代 java 应用（jdk 17+、spring boot 3.x）里稳定工作，必须绕过常见误区，从连接机制、事务模型和字符集三处硬刚。
Oracle AQ 的 JMS 接口不接受 jdbc:oracle:thin URL
很多人试图把 AQjmsFactory.getQueueConnectionFactory() 和 JDBC URL 混用，比如传入 "jdbc:oracle:thin:@localhost:1521:ORCL" ——这会直接失败，报 ORA-12154: TNS could not resolve the connect identifier。因为 AQ 的 JMS 实现底层依赖 Oracle 客户端的 TNS 解析能力，而非 JDBC 驱动本身。
- 必须用完整 TNS 描述符或已注册的
tns_alias，例如：(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orclpdb))) - 不能省略
SERVICE_NAME（用SID在 12c+ 多租户环境下大概率连不上） - 如果用 Oracle Wallet 或 LDAP，
java.naming.provider.url必须指向ldap://...或file:/path/to/wallet，而不是 JDBC 字符串
AQjmsXAConnectionFactory 才能保证事务一致性
非 XA 的 AQjmsConnectionFactory 无法绑定数据库事务。哪怕你调用了 session.commit()，也只是提交了出队动作，SQL 更新仍可能回滚，造成“消息已消费但业务未生效”的状态撕裂。
- 必须使用
AQjmsXAConnectionFactory，并搭配JtaTransactionManager或DataSourceTransactionManager（取决于你是否启用 JTA） - 入队/出队操作必须在
XAConnection创建的XASession中进行，普通Session不参与两阶段提交 - Spring Boot 中需手动注册
XAConnectionFactoryBean，并禁用默认的JmsAutoConfiguration
数据库字符集不是 AL32UTF8，中文就静默乱码
这是最隐蔽的坑：JMS TextMessage 收到的中文变成问号或方块，但既不抛异常，也不记录日志。根本原因是 Oracle AQ 的 JMS 层在序列化时硬编码使用数据库字符集解码 payload，而 AL32UTF8 是唯一被完整支持的 Unicode 字符集。
- 检查方式：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';，如果不是AL32UTF8，别挣扎，重建库或改应用层编码逻辑 - 临时绕过方案（不推荐）：改用
BytesMessage+ 手动 UTF-8 编解码，但会丢失 JMS 标准语义（如 message selector 不再可用） - DBA 创建队列表时，必须显式指定
compatible => '12.2.0'及以上，否则即使字符集正确，某些 JMS header 字段也可能被截断
真正卡住人的从来不是代码写几行，而是权限没授全、TNS 没配对、字符集不对——这三处任何一个出错，AQ 都不会明确告诉你哪里错了，只会让消息“消失”或“卡住”。尤其注意 DEQUEUE_ANY 权限必须由 DBA 显式执行 DBMS_AQADM.GRANT_QUEUE_PRIVILEGE 授予具体队列名，仅给角色权限是不够的。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
