启用JBoss SSL端口后CPU使用率飙升问题咨询

嘿，结合你描述的场景（之前LB侧做SSL卸载，现在要加密JBoss和LB之间的流量，启用后CPU暴增），我来拆解下最可能的几个原因：

1. SSL/TLS握手的计算开销拉满 #

咱们先从最核心的点说起：SSL连接建立时的全量握手是CPU密集型操作。如果负载均衡器和JBoss之间没有配置长连接，或者连接复用率极低，每次请求都要新建连接、完成完整的密钥交换+证书验证流程，CPU肯定扛不住。
另外，如果你们用的是RSA这类传统非对称加密算法做密钥交换，计算量比ECDHE椭圆曲线算法大得多。老版本的JBoss默认可能没启用ECDHE，这也是CPU飙升的常见诱因。

2. 没利用硬件加密加速，全靠CPU硬扛 #

JBoss的加密操作依赖JVM的加密库，如果你的服务器支持AES-NI这类硬件加密指令集，但JVM没配置启用，所有加密解密都靠CPU软计算，流量上来后CPU直接跑满太正常了。
你可以检查下JVM启动参数，有没有配置优先使用硬件加速的加密提供者，比如通过-Djava.security.properties指定自定义配置，让JVM优先调用硬件加速的算法实现。

3. SSL会话复用没配置到位 #

SSL会话复用（Session Resumption）是降低握手开销的关键——如果能复用之前的会话，就不用每次都做全量握手。但如果JBoss侧没开启会话缓存，或者和LB的会话复用方式不匹配（比如LB用会话ID，JBoss却只开了会话ticket，反之亦然），那复用率上不去，CPU还是会被频繁握手拖垮。
你可以去JBoss的SSL配置里看看，有没有设置ssl-session-cache-size（会话缓存大小）和ssl-session-timeout（会话超时时间），确保缓存足够容纳常用的会话。

4. 证书相关的额外开销 #

如果你们用的证书链过长，或者没开启OCSP stapling，JBoss在握手时要做更多的证书解析、验证甚至在线查询证书状态的操作，这也会额外消耗CPU。
建议检查下证书链是否完整，有没有在JBoss里配置OCSP stapling来减少证书状态查询的开销。

5. 线程池/连接池配置不匹配SSL场景 #

启用SSL后，每个连接的处理开销比纯HTTP大很多。如果JBoss的线程池（比如Undertow的worker线程）配置过小，会导致线程频繁上下文切换；如果配置过大，CPU核心被过度抢占，都会拉高CPU使用率。
一般建议把Undertow的io-threads设为服务器CPU核心数，worker-threads设为核心数的2-4倍，根据实际负载调整。

内容的提问来源于stack exchange，提问作者Harry