我们的服务器应用程序在一些客户那里遇到了极端缓慢的问题。通过重新启动服务器解决了这个问题，但是几周后它又回来了。
Java CPU始终保持在100%左右（满分200%），所有其他参数都正常。研究表明，大部分CPU都被“HandshakeCompletedNotify-Thread”线程消耗。从tcp转储中，我们看到SSL握手需要2-8秒，这是非常长的时间，有时会引发超时。
我们的SSL提供程序是BSAFE。服务器运行在Linux（CentOS）上，640 MB堆，2个内核。使用Hibernate、Spring、Oracle本地数据库
这种行为的原因可能是什么？可以做些什么来找到它们？
P.S.我们不能在我们的客户端将流量切换到HTTP。
更新：当java进程的输出连接被IP表阻塞时，系统被完全释放。在这种情况下，什么资源被释放？我们看到SSL握手经常在“更改密码规范”阶段卡住。客户端（我的java进程）试图重用SSL会话，但服务器是完全无状态的，它每次都生成新的会话。
4条答案
按热度按时间xdyibdwo1#
这是Sun在6u10中推出下一代Java插件时引入的一个已知错误。Oracle最终在Java 7u2中修复了它，但他们还没有将其后移植到Java 6，至少在6u33中是这样。
有关错误#7060523的详细信息，请参阅here。
exdqitrt2#
您可能需要查看针对JBoss报告的this issue（不确定这是否是您正在使用的）。这个问题表明
HandshakeCompletedNotify-Thread可能会抛出ConcurrentModificationException，这是竞争条件的一个可能结果。其他结果包括代码陷入无限循环并锁定CPU，这听起来像您的症状。如果您正在使用JBoss，我会考虑升级它。或与导致报告的问题相关的库。它可能会修复您的问题。aor9mmx13#
您可以尝试切换到JRE默认的JSSE实现，以查看是否存在BSAFE错误。
启用JSSE调试代码也很有价值（
javax.net.debug属性）。这些链接对于调试JSSE非常有用
http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#Debug
http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/ReadDebug.html
qltillow4#
你分析过你的DNS查找了吗？当DNS查找很慢的时候，SSL握手可能需要更长的时间，它需要查找和反向查找才能有效。