String 类有一些方法，我不明白为什么要这样实现它们...replace 就是其中之一。

public String replace(CharSequence target, CharSequence replacement) {
    return Pattern.compile(target.toString(), Pattern.LITERAL).matcher(
            this).replaceAll(Matcher.quoteReplacement(replacement.toString()));
}

与更简单、更高效(快速!)的方法相比，是否有一些明显的优势？

public static String replace(String string, String searchFor, String replaceWith) {

    StringBuilder result=new StringBuilder();

    int index=0;
    int beginIndex=0;
    while((index=string.indexOf(searchFor, index))!=-1){
        result.append(string.substring(beginIndex, index)+replaceWith);
        index+=searchFor.length();
        beginIndex=index;
    }
    result.append(string.substring(beginIndex, string.length()));

    return result.toString();

}

Java 7 的统计数据:
1,000,000 次迭代
将“a.b.c”中的“b”替换为“x”
结果:“a.x.c”

次数:
string.replace: 485ms
string.replaceAll: 490ms
优化替换 = 180ms

像 Java 7 split 方法这样的代码经过大量优化，可以尽可能避免模式编译/正则表达式处理:

public String[] split(String regex, int limit) {
    /* fastpath if the regex is a
     (1)one-char String and this character is not one of the
        RegEx's meta characters ".$|()[{^?*+\\", or
     (2)two-char String and the first char is the backslash and
        the second is not the ascii digit or ascii letter.
     */
    char ch = 0;
    if (((regex.value.length == 1 &&
         ".$|()[{^?*+\\".indexOf(ch = regex.charAt(0)) == -1) ||
         (regex.length() == 2 &&
          regex.charAt(0) == '\\' &&
          (((ch = regex.charAt(1))-'0')|('9'-ch)) < 0 &&
          ((ch-'a')|('z'-ch)) < 0 &&
          ((ch-'A')|('Z'-ch)) < 0)) &&
        (ch < Character.MIN_HIGH_SURROGATE ||
         ch > Character.MAX_LOW_SURROGATE))
    {
        int off = 0;
        int next = 0;
        boolean limited = limit > 0;
        ArrayList<String> list = new ArrayList<>();
        while ((next = indexOf(ch, off)) != -1) {
            if (!limited || list.size() < limit - 1) {
                list.add(substring(off, next));
                off = next + 1;
            } else {    // last one
                //assert (list.size() == limit - 1);
                list.add(substring(off, value.length));
                off = value.length;
                break;
            }
        }
        // If no match was found, return this
        if (off == 0)
            return new String[]{this};

        // Add remaining segment
        if (!limited || list.size() < limit)
            list.add(substring(off, value.length));

        // Construct result
        int resultSize = list.size();
        if (limit == 0)
            while (resultSize > 0 && list.get(resultSize - 1).length() == 0)
                resultSize--;
        String[] result = new String[resultSize];
        return list.subList(0, resultSize).toArray(result);
    }
    return Pattern.compile(regex).split(this, limit);
}

按照替换方法的逻辑:

public String replaceAll(String regex, String replacement) {
    return Pattern.compile(regex).matcher(this).replaceAll(replacement);
}

拆分实现应该是:

public String[] split(String regex, int limit) {
    return Pattern.compile(regex).split(this, limit);
}

性能损失与在替换方法中发现的损失相差不远。出于某种原因，Oracle 对某些方法而非其他方法提供了快速路径方法。

最佳答案

您确定您提出的方法确实比 String 类使用的基于正则表达式的方法更快 - 不仅针对您自己的测试输入，而且针对程序可能抛出的每个可能输入它？它依赖于 String.indexOf 来进行子串匹配，这本身就是一个天真的实现，会受到最坏情况下性能的影响。 Pattern 完全有可能实现更复杂的匹配算法，例如 KMP以避免多余的比较。

一般来说，Java 团队非常重视核心库的性能，并使用广泛的真实世界数据维护大量内部基准测试。我从未遇到过正则表达式处理成为瓶颈的情况。我的一贯建议是从编写能够正常工作的尽可能简单的代码开始，甚至不要开始考虑重写 Java 内置代码，直到分析证明它是一个瓶颈，并且您已经用尽所有其他优化途径。

关于您最近的编辑 - 首先，我不会将 split 方法描述为高度优化。它处理一种恰好非常常见的特殊情况，并保证不会遇到上面描述的朴素字符串匹配算法最差的最坏情况的复杂性——在单个字符、文字标记上进行拆分。

很可能相同的特殊情况可以针对 replace 进行优化，并且会提供一些可衡量的改进。但是看看实现这个简单的优化需要什么——大约 50 行代码。这些代码行是有代价的，尤其是当它们是 Java 库中可能使用最广泛的类的一部分时。成本有多种形式:

• 资源 - 这是 50 行代码，某些开发人员必须在 Java 语言的整个生命周期内花费时间编写、测试、记录和维护这些代码。
• 风险 - 有 50 次出现细微错误的机会，这些错误会漏过初始测试。
• 复杂性 - 这是 50 行额外的代码，任何想了解该方法如何工作的开发人员现在都必须花时间阅读和理解。

您的问题现在可以归结为“为什么对这种方法进行了优化以处理特殊情况，而不是另一种？”或者更笼统地说“为什么这个特定功能没有实现？”除了原作者，没有人可以明确地回答这个问题，但答案几乎总是要么对该功能没有足够的需求，要么拥有该功能所带来的好处被认为不值得添加它的成本。

关于java - JVM 字符串方法实现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24121793/