对于修改后的 Q：
您的第一个链接是（Oracle，因此是 OpenJDK）java 7 而不是 8；7 和 8 之间的 TLS 密码套件支持存在差异，但不会影响您命名的密码套件。您的“最高 1.8”链接适用于IBM Java，它使用不同的加密提供程序，并且不是 Oracle/OpenJDK 加密的好文档。请注意，该链接上的问题特别是“... IBM Java 支持的密码套件”——不是 Oracle/OpenJDK Java。对于 Oracle/OpenJDK 8，请参见https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites，对于 11，请参见https://docs.oracle.com/en/java /javase/11/docs/specs/security/standard-names.html#jsse-cipher-suite-names. 两者都包括 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 并且正如预期的那样，它适用于我在 Oracle 11.0.2 和 8 的多个版本。8 中支持的所有TLSv1.2 密码套件在 11 中仍然受支持，尽管 11还支持 TLSv1.3（你显然不是使用）。
除了如所评论的那样，Java 默认值通常在提供安全性方面比不知道自己在做什么的人覆盖更好，您在其他Q 中报告的异常（但未在此处提供）
javax.net.ssl.SSLHandshakeException: Invalid ECDH ServerKeyExchange signature
绝不表示您命名的密码套件不受支持。首先，请明确你的应用是TLS客户端还是服务器——即使应用协议中没有客户端/服务器关系，TLS协议中也始终存在；这就是 TLS（以及之前的 SSL）的定义方式。其次，遵循 SSL/TLS=JSSE 调试的标准说明，使用系统属性运行javax.net.debug=ssl并显示结果输出（可能只是最后 100 行左右，因为它非常庞大）。
最初的 Q 更加模糊，似乎是关于 RC4，但实际上并非如此。
您的问题文本不知道您的意思是什么“密码套件算法”，但您标记了 RC4-cipher。如果您的问题是使用 TLS 1.2 或更早版本中包含 RC4 的（任何）密码套件，那么您不应该这样做。RC4 在 2015 年 2 月被RFC7465禁止用于 TLS ，因为对它的密码分析攻击的快速发展。这适用于 2015 年存在的所有 TLS 协议版本（1.0、1.1 和 1.2），并由所有受支持的 Java 版本实现：从 8u60 开始的 8，以及 9 及更高版本的所有版本。
如果您真的想使用 RC4 并冒着被攻击者窃取您数据的风险——也许它实际上是错误的、无意义的或毫无价值的——要么更改java.security文件中的设置，要么在程序的早期调用Security.setProperty（在加载 JSSE 之前）；请参阅 JSSE 参考指南，例如 Java11。请注意，在 j8 中，文件位置不同，<JREhome>/lib/security/java.security. 另请参阅Java 8 更新后的 RC4 相关问题。
如果并且当您（想要或需要）使用 Java 11 及更高版本支持的 TLS 1.3 时，这不再是一种选择。TLS 1.3 仅支持 AEAD 密码（或模式），而最初定义的 RC4 不支持，并且今天不会接受任何基于 RC4 的 AEAD 构造提案。
另一方面，如果您只想使用良好、安全的密码套件，请不要更改任何内容，只需使用默认值即可。默认值之所以是默认值，正是因为它们是安全的，至少就目前所知而言。如果分析改进改变了这一点，那么默认值将相应地改变，并且您使用它们的程序也将是安全的，而无需您制作、测试、分发和验证新版本。