Brian Goetz在最近一篇关于InfoQ的文章中提到，制作Stringfinal会导致问题：
我们为这种张力付出代价的一个很好的例子是 String;字符串是不可变的，因此 String 不能公开扩展，这对平台的安全性至关重要——但实现有多个子类型会非常方便。(解决这个问题的成本很高;紧凑字符串通过对仅由拉丁语 1 字符组成的字符串进行特殊处理，提供了显著的占用空间和性能改进，但如果 String 是密封类而不是最终类，则这样做会容易得多，成本也会低得多。
他还提到，sealed创建一个final类是向后兼容的：
这是一个二进制和源代码兼容的更改，用于密封现有的最终类。密封一个您尚未控制所有实现的非最终类既不兼容二进制也不兼容源代码。
是否打算回到 Java 平台中的一些final类并使它们sealed以获得性能优势(即，通过一些高性能实现来制作Stringsealed而不是final(？
你要求预测未来，但听起来有点像你期望有很多类会从性能调优中受益。此外，如果需要改进，并不是需要密封来改进，只是例如，它可能会使String更容易。现在封印String并不像10年前封印时那样有用。
String一直是一个非常特殊和重要的案例，因此即使没有密封类，它也被广泛调谐(和解调(：实习、共享 char 数组、压缩和紧凑字符串。这样做一直有一个很好的动机，因为从任何内存转储中都非常清楚地看出String(或者更确切地说是其内部char[]，在更高版本中是一个byte[](是应用程序中占用最多内存的原因。
你认为有一个最终的类真的应该调整，还是你只是假设这些类没有性能？或者您是否希望对代码库进行某种常规清理，考虑到您需要进行更改以最大程度地提高性能，这可能会导致非常低的投资回报率，但您需要进行大量测试。
此外，其他重要的非字符串类也以各种方式进行了调整，你有整数缓存，JVM内部函数和许多其他东西，所以密封不是主要(甚至次要(的性能工具。