京公网安备11010502063487号在 JDK 21 上用同一个 JVM 里的 SaslClient / SaslServer 验证 SASL:服务端机制只有 DIGEST-MD5、NTLM、CRAM-MD5、GSSAPI,PLAIN 只有客户端,没有 SCRAM / OAUTHBEARER;CRAM-MD5 的响应是确定性的 HMAC-MD5;DIGEST-MD5 的 4 个报文与 rspauth;QOP 与强度协商;auth-int / auth-conf 的 wrap 开销,篡改后的 unwrap 不抛异常而返回空数组。
在 JDK 21 上用本机 HTTP 服务与代理验证 java.net.Authenticator:HttpURLConnection 的凭证按主机缓存、错误口令 20 次后 401、URL 里的 userinfo 不被使用;HttpClient 限制 3 次并抛 IOException,不使用全局 Authenticator;Digest 的 MD5 默认被拒绝(需要 http.auth.digest.reEnabledAlgorithms),HttpClient 不支持 Digest;代理认证的请求者类型 PROXY。
在本机真实的 PostgreSQL 16.15 与 MySQL 26.7.0 上对比 DatabaseMetaData:schema / catalog 的映射(MySQL getSchemas 为 0 个)、getTypeInfo 407 对 44、默认隔离级别 READ_COMMITTED 对 REPEATABLE_READ;supportsBatchUpdates 为 true 但 MySQL 批处理 select 会抛异常;getTables 里 _ 是通配符;getExportedKeys 在 MySQL 返回重复行;2000 张表的查询耗时。
在 PostgreSQL 16.15 与 MySQL 26.7.0 上实测 CallableStatement:PG 驱动默认把 {call …} 翻成 SELECT,调用 PROCEDURE 会失败,需要 escapeSyntaxCallMode=call 或 callIfNoReturn;PG 不支持按名字传参,MySQL 支持;OUT 参数省略、类型登记错误的行为;多结果集与 OUT 参数;refcursor 要 autoCommit=false;MySQL 每次 prepareCall 约 658 µs,复用约 102 µs。
在 PostgreSQL 16.15 与 MySQL 26.7.0 上实测 SQLWarning:PG 的 NOTICE / WARNING 变成 PSQLWarning 挂在 Statement 上,client_min_messages 控制数量,超长字符串直接报错;MySQL 非严格模式下超长、越界、非法日期被静默改写,只留下 4 条警告,且只保留最近一条语句的;严格模式或 jdbcCompliantTruncation=true 抛 MysqlDataTruncation;executeBatch 之后警告丢失。
在 PostgreSQL 16.15(xml 列)与 MySQL 26.7.0(longtext 列)上实测 SQLXML:一次写入限制、XML 声明在 PG 里被去掉、PG 的 xml 列校验而 MySQL 不校验;getSource 对 DOM / SAX 禁用 DOCTYPE,但 StreamSource 配合默认 Transformer 会解析外部实体并读到 /etc/hosts;MySQL 的 StAXSource 抛 NPE、SAXResult 读回缺结束标签;7 MB 文档的读写耗时。
在 PostgreSQL 16.15 与 MySQL 26.7.0 上实测 JDBC Array / Struct:PG 数组的元素类型与还原(NULL 元素、特殊字符、二维数组)、下标从 1 开始的越界错误;MySQL 不支持 Array / Struct,且 setObject(Integer[]) 会把数组序列化后发给服务器;= ANY(?) 对比 IN 列表(10000 个 id:4.40 对 10.17 ms);PG 复合类型只能通过 PGobject 访问。
在 PostgreSQL 16.15 与 MySQL 26.7.0 上用 HikariCP 6.2.1 实测:归还时重置了 autoCommit / readOnly / 隔离级别并 rollback 未提交事务,但 SET 会话变量、setSchema / setCatalog、临时表、advisory lock / get_lock 都泄漏给下一个使用者;池耗尽 1 秒后抛异常;泄漏检测;杀掉连接后 500 ms 内再借会拿到坏连接;新建连接约 1.2–1.6 ms,池里借出约 30 µs。
在嵌入式 Jetty 12.0.16 上实测 Servlet 生命周期:以实例注册的 servlet 启动时全部 init、按类注册的才在第一次请求 init;一个实例处理所有请求(64 并发把非同步 int 的 128000 次加法丢失 186 次);请求对象回收后 getRequestURI 抛 NPE;init 失败后 Jetty 不再重试(第 1 次 500、之后 404);stop 时 stopTimeout 不够会中断请求;异步把 8 个 500 ms 请求从 2041 ms 降到 601 ms。
在嵌入式 Jetty 12.0.16 上实测 Servlet Filter:链的顺序是声明顺序而不是路径匹配的精确程度、destroy 逆序;不调用 chain.doFilter 的短路与调用两次的后果;请求 / 响应包装;小响应未提交时过滤器在 chain 之后改状态码生效、大响应已提交则被静默忽略;DispatcherType 对 forward / include / error 的作用;异步请求中过滤器的「后」先于请求结束。
在 Hibernate Validator 8.0.1 上实测 Bean Validation:null 对大多数约束合法、@Email 接受空串;容器元素与 @Valid 级联的路径;@GroupSequence 阻止后组执行;方法验证不会自动拦截直接调用;自定义模板里的 ${...} 不求值但 {key} 仍被插值;验证稳态约 2 µs,而每次新建 ValidatorFactory 约 3.1 ms;Validator 线程安全。
在 Weld SE 5.1.3 上实测 CDI:@ApplicationScoped / @RequestScoped 注入的是延迟创建的代理(代理上的字段是 null),@Dependent 与 @Singleton 不是代理;final 类 / final 方法 / public 字段无法作普通作用域 bean(启动即报错);拦截器不拦截同类内部调用;@Dependent 循环依赖启动失败;歧义与缺失在启动时报 WELD-001409 / 001408;经代理调用约 77 ns。