【编者按】本文展示了如何利用 Java 的一个 bug 来制造一些奇怪的字符串，包括字符串相等性的条件、创建损坏字符串的方法以及利用该 bug 在另一个类中远程破坏字符串的示例并提出了一个挑战，要求读者创建一个满足特定条件的损坏空字符串，最终揭晓了网友提供的多种实现方法。
原文链接：https://wouter.coekaerts.be/2023/breaking-string讨论链接：https://news.ycombinator.com/item?id=36687970
未经允许，禁止转载！作者 | Wouter Coekaerts 译者 | 明明如月责编 | 夏萌出品 | CSDN（ID：CSDNnews）本文将展示如何利用 java.lang.String
中的一个 bug 来制造一些奇怪的字符串我们将使 “hello world” 不以“hello”开头, 并展示并不是所有的空字符串都相等介绍：字符串之间的相等的条件在我们开始之前，我们看一下 JDK 中两个字符串相等需要什么。
为什么 "foo".equals("fox") 的结果是 false?因为字符串是逐字符比较的，这两个字符串的第三个字符不同为什么 "foo".equals("foo") 的结果是 true?你可能会认为在这种情况下，字符串也是逐字符比较的。
但是字符串字面量是 intern 的，当相同的字符串在源代码中出现多次作为常量时，它不是具有相同内容的另一个字符串，这些字符串是同一个实例String.equals 的第一件事就是 if (this == anObject) { return true; }
, 这里的判断甚至都不会去看里面的内容为什么 "foo!".equals("foo!?") 的结果是 false?从 JDK 9 开始(自从 JEP 254: 紧凑字符串)，字符串在内部表示其内容为字节数组。
"foo!" 只包含简单的字符，代码点小于 256字符串类在内部使用 latin-1 编码来编码这样的值，每个字符一个字节"foo!?" 包含一个不能用 latin-1 表示的字符(!?)，所以它使用 UTF-16 来编码整个字符串，每个字符两个字节。
String.coder 字段跟踪使用了两种编码中的哪一种当比较两个使用不同 coder 的字符串时，String.equals 总是返回 false它甚至不去看内容，因为如果一个字符串可以用 latin-1 表示，而另一个字符串不可以，那么它们就不能相同。
难到，你会认为可以相等？注意: 紧凑字符串（Compact Strings）特性可以禁用，但默认是启用的本文假定它是启用的创建一个损坏的字符串字符串是如何创建的? java.lang.String 是如何选择使用 latin-1 还是不使用它的?
可以通过多种方式创建字符串，我们将关注接受 char[] 的字符串构造函数它首先尝试使用 StringUTF16.compress 将字符编码为 latin-1如果失败，返回 null，构造函数退回到使用 UTF-16。
这里是它的实现的简化版本(为了可读性,我从实际实现中删除了不相关的间接调用、检查和参数，实际实现在这里（https://github.com/openjdk/jdk/blob/b3f34039fedd3c49404783ec880e1885dceb296b/src/java.base/share/classes/java/lang/String.java#L277-L279）和
这里（https://github.com/openjdk/jdk/blob/b3f34039fedd3c49404783ec880e1885dceb296b/src/java.base/share/classes/java/lang/String.java#L4757-L4772）)
/** * 分配一个新的 {@code String} 以表示字符数组参数当前所包含的字符序列 * 复制字符数组的内容;后续修改字符数组不会影响新创建的字符串 */publicString(charvalue
[]) {byte[] val = StringUTF16.compress(value);if (val != null) {this.value = val;this.coder = LATIN1;
return; }this.coder = UTF16;this.value = StringUTF16.toBytes(value);}这里有个 bug这段代码并不总是保持 String.equals 。
的语义，我们之前讨论过你看出来了吗?javadoc 指出“对字符数组的后续修改不会影响新创建的字符串”但是并发修改呢？在尝试将其编码为 latin-1 和将其编码为 UTF-16 之间，value 的内容可能已经改变了。
这样我们就可以拥有只包含 latin-1 字符的字符串，但编码却为 UTF-16我们可以通过下面的方式触发这个竞争条件:/** * 给定一个 latin-1 字符串，创建一个错误编码为 UTF-16 的副本。
*/staticString breakIt(String original) {if (original.chars().max().orElseThrow() > 256) {thrownew IllegalArgumentException(
"只能打断 latin-1 字符串"); } char[] chars = original.toCharArray();// 在另一个线程中，反复将第一个字符在可作为 latin-1 编码和不可作为 latin-1 编码之间切换
Thread thread = new Thread(() -> {while (!Thread.interrupted()) { chars[0] ^= 256; } }); thread.start();
// 同时调用字符串构造函数,直到触发竞争条件while (true) {String s = newString(chars);if (s.charAt(0) 256 && !original.equals(s)) {
thread.interrupt();return s; } }}我们可以使用这种方法创建的“损坏字符串”具有一些有趣的特性String a = "foo";String b = breakIt(a);。
// 它们不相等System.out.println(a.equals(b));// => false// 它们确实包含相同的一系列字符System.out.println(Arrays.equals(a.toCharArray(),
b.toCharArray())); // => true// compareTo 认为它们相等(尽管它的 javadoc// 指定“当且仅当 equals(Object) 方法返回 true 时,
// compareTo 返回 0”)System.out.println(a.compareTo(b));// => 0// 它们有相同的长度,一个是另一个的前缀,// 但反过来不是(因为如果它没有被破坏,
// 一个 latin-1 字符串不能以一个非 latin-1 // 子串开头)System.out.println(a.length() == b.length());// => trueSystem.。
out.println(b.startsWith(a));// => trueSystem.out.println(a.startsWith(b));// => false没想到这样一个基础的 Java 类会有这种奇怪的行为。
神秘的远程作用我们不仅可以创建一个“损坏的字符串”，我们还可以在另一个类中远程破坏一个字符串classOtherClass {staticvoidstartWithHello() { System.。
out.println("hello world".startsWith("hello")); }}如果我们在 IntelliJ 中编写这段代码，那么它会警告我们 Result of "hello world".startsWith("hello") is always true。
这段代码甚至不需要任何输入，但我们仍然可以通过注入一个损坏的 "hello" 来使其打印 false，通过 interning：我们在任何其他代码字面量提及或显式 intern 它之前就破坏一个包含 hello 的字符串，并 intern 该损坏版本。
这样，我们就破坏了JVM 中的每个 "hello" 字符串字面量breakIt("hell".concat("o")).intern();OtherClass.startWithHello(); // 打印
false挑战：空或非空?使用我们的 breakIt 方法，我们可以创建任何 latin-1 字符串的等价但不相等的字符串但是它对空字符串不起作用，因为空字符串没有任何字符来触发竞争条件然而，我们仍然可以创建一个损坏的空字符串。
我将这个作为一个挑战给读者具体来说：你能创造一个 java.lang.String 对象，对于该对象，以下是真的 :s.isEmpty() && !s.equals("")不要作弊：你只允许使用公共 API 来做这件事，如，不允许使用 。
.setAccessible 访问私有字段，也不允许使用 instrumentation 相关的类（因为 Instrumentation 提供了一种机制，使得开发者可以在不修改原始代码的情况下，通过代理、注入代码和监视器等方式对应用程序进行动态修改和扩展）。
如果你挑战成功，请在这里告诉我我会在以后更新这篇文章，添加你提交的答案揭晓答案创建一个 "损坏的" 空字符串最简单的方法是使用 breakIt(" ").trim()这是因为 trim 方法正确地假定，如果原始字符串包含 latin-1 字符，那么去除 latin-1 字符后的结果仍应包含非 latin-1 字符。
这个答案是由：Zac Kologlu、Jan、ichttt、Robert（他正确地指出了我对 "> 256" 检查的偏差）给出我还收到了两个原创的只能在 JDK 19 上运行的 StringBuilder
解决方案Ihor Herasymenko 提交了这段代码，该代码通过 StringBuilder 的 deleteCharAt 触发了一个竞态条件Ihor 使用 deleteCharAt ：public。
classBrokenEmptyStringChallenge {publicstaticvoidmain(String[] args) { String s = breakIt(); System.
out.println("s.isEmpty() && !s.equals(\"\") = " + (s.isEmpty() && !s.equals(""))); }static String
breakIt() { String notLatinString = "\u0457"; AtomicReference sb = new AtomicReference<>(
new StringBuilder(notLatinString)); Thread thread = new Thread(() -> {while (!Thread.interrupted()) {
sb.get().deleteCharAt(0); sb.set(new StringBuilder(notLatinString)); }
}); thread.start();while (true) { String s = sb.get().toString();if (s.isEmpty() && !s.
equals("")) { thread.interrupt();return s; } } }}最后，Xavier Cooney 提出了这个绝妙的解决方案，它甚至不涉及任何并发操作。
它从 CharSequence.charAt 抛出一个异常，从而导致 StringBuilder 的状态不一致来实现这个效果这看起来像是另一个 JDK 的 bugXavier 给出的从 CharSequence.charAt 。
抛出异常的方案：// 要求 Java 19+classWatSequenceimplementsCharSequence {public CharSequence subSequence(int start,
int end) {returnthis; }publicintlength() {return2; }publiccharcharAt(int index) {// 无需并发处理！if (index ==
1) thrownew RuntimeException();return⁉; }public String toString() {return"wat"; }}classWat {static
String wat() {if (Runtime.version().feature() < 19) {thrownew RuntimeException("本示例在 java-19 之前的版本无法运行 :("
); } StringBuilder sb = new StringBuilder();try { sb.append(new WatSequence());
} catch (RuntimeException e) {}returnnew String(sb); }publicstaticvoidmain(String[] args) {
String s = wat(); System.out.println(s.isEmpty() && !s.equals("")); }}我已经将这个 bug 提交到
Java Bug 数据库中本文引发了网友的激烈讨论，不同的网友发表了不同的看法有些网友认为这不是 bug，Java 中的一些类除非特殊说明否则本身就不是线程安全的，采用非线程安全的方式来破坏它，本身符合预期。
作者则坚称这就是 bug，因为人们通常会认为核心类库的不可变类是线程安全的通无论用户如何去破坏，都不能破坏内部的结构而且这个 bug 已经提交到 Java 的 bug 数据库中，预计未来版本中将会被修复。
有些网友甚至认为这不仅是 String 的 bug ，还是 JVM 的安全漏洞也有网友认为，加一些防御性编程代码就可以解决这个问题同时，也有一些网友称，Java 内存模型是一个伟大的创造，如果你遵循它的规范，就能够以其他语言难以实现的简易度编写高性能的多线程应用程序。
如果你不遵循 Java 内存模型的规范，就可能出乱子你是否曾经认为 JDK 是不会有 bug 的？你是否发现过JDK 的 bug? 你认为 Java 语言有哪些缺点？欢迎在留言区交流讨论。
亲爱的读者们，感谢您花时间阅读本文。如果您对本文有任何疑问或建议，请随时联系我。我非常乐意与您交流。
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。