String用Java剥离所有不可打印字符的最快方法是什么？

到目前为止，我已经尝试并测量了138字节，131个字符的字符串：

• 字符串的replaceAll()-最慢的方法
  • 517009个结果/秒
• 预编译模式，然后使用Matcher的 replaceAll()
  • 637836个结果/秒
• 使用StringBuffer，使用codepointAt()一对一获取代码点并追加到StringBuffer
  • 711946结果/秒
• 使用StringBuffer，使用charAt()一对一获取字符并追加到StringBuffer
  • 1052964结果/秒
• 预分配char[]缓冲区，使用charAt()一对一获取字符并填充该缓冲区，然后转换回String
  • 2022653个结果/秒
• 预分配2个char[]缓冲区-旧的和新的，使用一次获取现有String的所有字符，一次又一次getChars()遍历旧缓冲区并填充新缓冲区，然后将新缓冲区转换为String-我自己最快的版本
  • 2502502结果/秒
• 具有2个缓冲区的相同内容-仅使用byte[]，getBytes()并将编码指定为“ utf-8”
  • 857485结果/秒
• 具有2个byte[]缓冲区的相同内容，但将编码指定为常量Charset.forName("utf-8")
  • 791076个结果/秒
• 具有2个byte[]缓冲区的相同内容，但是将编码指定为1字节本地编码（几乎没有理智的事情）
  • 370164结果/秒

我的最佳尝试是：

    char[] oldChars = new char[s.length()];
    s.getChars(0, s.length(), oldChars, 0);
    char[] newChars = new char[s.length()];
    int newLen = 0;
    for (int j = 0; j < s.length(); j++) {
        char ch = oldChars[j];
        if (ch >= ' ') {
            newChars[newLen] = ch;
            newLen++;
        }
    }
    s = new String(newChars, 0, newLen);

关于如何使其更快的想法？

回答一个非常奇怪的问题的好处是：为什么直接使用“ utf-8”字符集名称会比使用预分配的静态const产生更好的性能Charset.forName("utf-8")？

更新资料

• 棘轮怪胎的建议可产生令人印象深刻的3105590结果/秒性能，提高了+ 24％！
• Ed Staub的建议带来了另一个改进-3471017个结果/秒，比以前的最佳增长了+ 12％。

更新2

我已尽力收集了所有建议的解决方案及其交叉变异，并将其作为小型基准测试框架发布在github上。目前，它采用17种算法。其中之一是“特殊的” -Voo1算法（由SO用户Voo提供）使用复杂的反射技巧，从而达到了惊人的速度，但是却弄乱了JVM字符串的状态，因此进行了单独的基准测试。

欢迎您将其签出并运行以确定您的包装盒上的结果。这是我获得的结果摘要。它的规格：

• Debian SID
• Linux 2.6.39-2-amd64（x86_64）
• Java是从软件包安装的sun-java6-jdk-6.24-1，JVM将自身标识为
  • Java（TM）SE运行时环境（内部版本1.6.0_24-b07）
  • Java HotSpot（TM）64位服务器VM（内部版本19.1-b02，混合模式）

给定不同的输入数据集，不同的算法最终显示出不同的结果。我已经在3种模式下运行了基准测试：

相同的单个字符串

此模式适用于StringSource类提供的作为常量的同一单个字符串。摊牌是：

 操作数│算法
──────────┼────────────────────────
6535947│Voo1
──────────┼────────────────────────
5350454│RatchetFreak2EdStaub1GreyCat1
5249343│EdStaub1
5002501│EdStaub1GreyCat1
4859 086│ArrayOfCharFromStringCharAt
4295532│RatchetFreak1
4045307│ArrayOfCharFromArrayOfChar
2 790 178│RatchetFreak2EdStaub1GreyCat2
2583311│RatchetFreak2
1274859│StringBuilderChar
1138174│StringBuilderCodePoint
  994727│ArrayOfByteUTF8String
  918611│ArrayOfByteUTF8Const
  756 086│MatcherReplace
  598945│StringReplaceAll
  460045│ArrayOfByteWindows1251

以图表形式：（ _{来源：greycat.ru）}

多个字符串，其中100％的字符串包含控制字符

源字符串提供程序使用（0..127）字符集预先生成了大量随机字符串-因此几乎所有字符串都包含至少一个控制字符。算法以循环方式从此预生成的数组中接收字符串。

 操作数│算法
──────────┼────────────────────────
2123142│Voo1
──────────┼────────────────────────
1782214│EdStaub1
1776199│EdStaub1GreyCat1
1694628│ArrayOfCharFromStringCharAt
1481481│ArrayOfCharFromArrayOfChar
1460067│RatchetFreak2EdStaub1GreyCat1
1438435│RatchetFreak2EdStaub1GreyCat2
1366494│棘轮怪2
1349710│棘轮怪胎1
  893176│ArrayOfByteUTF8String
  817127│ArrayOfByteUTF8Const
  778089│StringBuilderChar
  734754│StringBuilderCodePoint
  377829│ArrayOfByteWindows1251
  224140│MatcherReplace
  211 104│StringReplaceAll

以图表形式：（ _{来源：greycat.ru）}

多个字符串，其中1％的字符串包含控制字符

与以前相同，但是只有1％的字符串是使用控制字符生成的-其他99％的字符串是使用[32..127]字符集生成的，因此它们根本不能包含控制字符。在我这个地方，这种合成负载最接近该算法的实际应用。

 操作数│算法
──────────┼────────────────────────
3711952│Voo1
──────────┼────────────────────────
2851440│EdStaub1GreyCat1
2455796│EdStaub1
2426007│ArrayOfCharFromStringCharAt
2347969│RatchetFreak2EdStaub1GreyCat2
2242152│RatchetFreak1
2171553│ArrayOfCharFromArrayOfChar
1922707│RatchetFreak2EdStaub1GreyCat1
1857010│棘轮怪2
1 023 751│ArrayOfByteUTF8String
  939 055│StringBuilderChar
  907194│ArrayOfByteUTF8Const
  841963│StringBuilderCodePoint
  606465│MatcherReplace
  501555│StringReplaceAll
  381185│ArrayOfByteWindows1251

以图表形式：（ _{来源：greycat.ru）}

我很难决定谁提供了最佳答案，但是鉴于实际应用中最佳解决方案是由Ed Staub提供/启发的，我想标记他的答案是很公平的。感谢所有参与此活动的人，您的意见非常有帮助且非常宝贵。随时在您的设备上运行测试套件，并提出更好的解决方案（正在使用JNI解决方案，有人吗？）。

参考文献

• 带有基准测试套件的GitHub存储库

如果将此方法嵌入在线程间不共享的类中是合理的，则可以重用缓冲区：

char [] oldChars = new char[5];

String stripControlChars(String s)
{
    final int inputLen = s.length();
    if ( oldChars.length < inputLen )
    {
        oldChars = new char[inputLen];
    }
    s.getChars(0, inputLen, oldChars, 0);

等等...

据我所知，这是一个巨大的胜利-20％左右。

如果要在可能较大的字符串上使用它，并且担心内存“泄漏”，则可以使用弱引用。

使用1个字符数组可能会更好

int length = s.length();
char[] oldChars = new char[length];
s.getChars(0, length, oldChars, 0);
int newLen = 0;
for (int j = 0; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

而且我避免了多次致电 s.length();

另一个可行的微优化是

int length = s.length();
char[] oldChars = new char[length+1];
s.getChars(0, length, oldChars, 0);
oldChars[length]='\0';//avoiding explicit bound check in while
int newLen=-1;
while(oldChars[++newLen]>=' ');//find first non-printable,
                       // if there are none it ends on the null char I appended
for (int  j = newLen; j < length; j++) {
    char ch = oldChars[j];
    if (ch >= ' ') {
        oldChars[newLen] = ch;//the while avoids repeated overwriting here when newLen==j
        newLen++;
    }
}
s = new String(oldChars, 0, newLen);

好吧，根据我的测量，我已经击败了当前最好的方法（使用预分配数组的怪胎解决方案）约30％。怎么样？通过卖掉我的灵魂。

我敢肯定，到目前为止，所有参与讨论的人都知道这几乎违反了任何基本的编程原理，但是哦。无论如何，以下内容仅在字符串的使用的字符数组未在其他字符串之间共享的情况下才有效-如果它必须调试，则将有一切权利决定杀死您（无需调用substring（）并将其用于文字字符串）这应该工作，因为我不明白为什么JVM会内生从外部源读取的唯一字符串）。尽管不要忘记确保基准代码不会这样做-这极有可能会明显地帮助反射解决方案。

无论如何，我们去了：

    // Has to be done only once - so cache those! Prohibitively expensive otherwise
    private Field value;
    private Field offset;
    private Field count;
    private Field hash;
    {
        try {
            value = String.class.getDeclaredField("value");
            value.setAccessible(true);
            offset = String.class.getDeclaredField("offset");
            offset.setAccessible(true);
            count = String.class.getDeclaredField("count");
            count.setAccessible(true);
            hash = String.class.getDeclaredField("hash");
            hash.setAccessible(true);               
        }
        catch (NoSuchFieldException e) {
            throw new RuntimeException();
        }

    }

    @Override
    public String strip(final String old) {
        final int length = old.length();
        char[] chars = null;
        int off = 0;
        try {
            chars = (char[]) value.get(old);
            off = offset.getInt(old);
        }
        catch(IllegalArgumentException e) {
            throw new RuntimeException(e);
        }
        catch(IllegalAccessException e) {
            throw new RuntimeException(e);
        }
        int newLen = off;
        for(int j = off; j < off + length; j++) {
            final char ch = chars[j];
            if (ch >= ' ') {
                chars[newLen] = ch;
                newLen++;
            }
        }
        if (newLen - off != length) {
            // We changed the internal state of the string, so at least
            // be friendly enough to correct it.
            try {
                count.setInt(old, newLen - off);
                // Have to recompute hash later on
                hash.setInt(old, 0);
            }
            catch(IllegalArgumentException e) {
                e.printStackTrace();
            }
            catch(IllegalAccessException e) {
                e.printStackTrace();
            }
        }
        // Well we have to return something
        return old;
    }

对于我的测试字符串，3477148.18ops/s与2616120.89ops/s旧版本相比。我敢肯定，击败它的唯一方法可能是用C编写（可能不是），或者到目前为止还没有人想到过的完全不同的方法。尽管我绝对不确定在不同平台上的计时是否稳定-至少在我的机器（Java7，Win7 x64）上产生可靠的结果。

您可以根据处理器的数量将任务分为几个并行的子任务。

我是如此自由，为不同的算法编写了一个小型基准测试。这并不完美，但是我在给定的字符串上最少进行了1000次给定算法的10000次运行（默认情况下约有32/200％的不可打印内容）。这应该处理诸如GC，初始化之类的工作-没有太多的开销，因此任何算法都不应在没有太大阻碍的情况下至少运行一次。

没有特别有据可查的，但是很好。在这里-我同时介绍了棘轮怪胎的算法和基本版本。目前，我随机地初始化了一个200个字符长的字符串，其均匀分布的字符范围为[0，200）。

IANA低级Java性能迷，但您是否尝试展开主循环？看来它可以允许某些CPU并行执行检查。

此外，这还有一些有趣的优化想法。

为什么直接使用“ utf-8”字符集名称会比使用预分配的静态const Charset.forName（“ utf-8”）直接产生更好的性能？

如果您是这样的话String#getBytes("utf-8")：不应更快-除了更好的缓存-由于Charset.forName("utf-8")内部使用了字符集（如果未缓存字符集），因此应该更快。

一件事可能是您使用的是不同的字符集（或者您的某些代码透明地使用了），但是缓存的字符集StringCoding没有改变。