《Effective Java》：为何String的contentEquals()被重载而非替代？

算力阿峰

2026-5-21

关于String类contentEquals方法重载的疑问解答

嘿，这个问题问得特别戳点！我当初啃《Effective Java》的时候也纠结过这事，咱们来好好唠唠为啥要这么设计～

性能优化是核心原因：Java 4里的contentEquals(StringBuffer)是专门为StringBuffer量身定制的优化版本。你要知道StringBuffer有个toStringCache的缓存字段，当它的内容没被修改时，这个缓存会保存对应的String实例。直接用这个缓存来和目标String做比对，比通过CharSequence接口逐个遍历字符要高效得多。如果只保留接收CharSequence的重载，那处理StringBuffer时就没法利用这个缓存优势，只能走通用的字符比对逻辑，性能会明显下降。
兼容性不能丢：Java 5推出CharSequence接口的时候，已经有海量老代码在使用contentEquals(StringBuffer)了。要是直接把这个方法移除，或者改成完全委托给新的重载方法，虽然功能上能正常运行，但老代码的性能会悄悄缩水，而且也没必要强迫开发者修改原本没问题的代码。保留这个重载版本，既能让老代码继续高效跑起来，又能给新代码提供更通用的CharSequence支持，完美兼顾新老系统。
API语义更清晰：contentEquals(StringBuffer)从方法签名就能直观看出是和StringBuffer做内容比对，而contentEquals(CharSequence)则覆盖了所有实现该接口的类（比如StringBuilder、String本身，甚至你自己写的自定义字符序列）。分开重载能让API的语义更明确，调用者不用额外判断参数类型，看方法名就知道该选哪个版本，代码可读性也更高。