我们都知道String在Java中是不可变的，但是检查下面的代码:
String s1 = "Hello World";
String s2 = "Hello World";
String s3 = s1.substring(6);
System.out.println(s1); // Hello World
System.out.println(s2); // Hello World
System.out.println(s3); // World
Field field = String.class.getDeclaredField("value");
field.setAccessible(true);
char[] value = (char[])field.get(s1);
value[6] = 'J';
value[7] = 'a';
value[8] = 'v';
value[9] = 'a';
value[10] = '!';
System.out.println(s1); // Hello Java!
System.out.println(s2); // Hello Java!
System.out.println(s3); // World
为什么这个程序是这样运行的?为什么s1和s2的值变了，而s3的值不变?
在Java中，如果两个字符串基元变量被初始化为相同的字面值，它会将相同的引用赋给这两个变量:
String Test1="Hello World";
String Test2="Hello World";
System.out.println(test1==test2); // true
这就是比较返回true的原因。第三个字符串是使用substring()创建的，它创建了一个新的字符串，而不是指向相同的字符串。
当你使用反射访问一个字符串时，你会得到实际的指针:
Field field = String.class.getDeclaredField("value");
field.setAccessible(true);
因此，更改this将更改持有指向它的指针的字符串，但由于substring()使用新字符串创建了s3，因此它不会更改。
字符串是不可变的*，但这只意味着你不能使用它的公共API更改它。
您在这里所做的是绕过常规API，使用反射。同样地，你可以改变枚举的值，改变Integer自动装箱中使用的查找表等等。
s1和s2改变值的原因是，它们都指向同一个被合并的字符串。编译器执行此操作(如其他答案所述)。
s3没有这样做的原因实际上让我有点惊讶，因为我认为它会共享值数组(在Java 7u6之前的早期版本中是这样的)。但是，查看String的源代码，我们可以看到子字符串的值字符数组实际上是复制的(使用Arrays.copyOfRange(..))。这就是它不变的原因。
你可以安装一个SecurityManager，避免恶意代码做这样的事情。但是请记住，有些库依赖于使用这种反射技巧(通常是ORM工具，AOP库等)。
*)我最初写的字符串不是真正的不可变，只是“有效的不可变”。在String的当前实现中，这可能会引起误解，其中值数组确实被标记为private final。不过，仍然值得注意的是，在Java中没有办法将数组声明为不可变的，因此必须注意不要在类之外公开它，即使使用适当的访问修饰符。
由于这个话题似乎非常受欢迎，这里有一些建议的进一步阅读:Heinz Kabutz在JavaZone 2009上的Reflection Madness演讲，它涵盖了OP中的许多问题，以及其他的反思……嗯…疯狂。
它涵盖了为什么这有时是有用的。以及为什么，大多数时候，你应该避免它。: -)
[免责声明，这是一个故意固执己见的回答风格，因为我觉得一个更“不要在家里这样做，孩子们”的回答是有保证的]
sin是line field.setAccessible(true);它说通过允许访问私有字段来违反公共API。这是一个巨大的安全漏洞，可以通过配置一个安全管理器来锁定。
The phenomenon in the question are implementation details which you would never see when not using that dangerous line of code to violate the access modifiers via reflection. Clearly two (normally) immutable strings can share the same char array. Whether a substring shares the same array depends on whether it can and whether the developer thought to share it. Normally these are invisible implementation details which you should not have to know unless you shoot the access modifier through the head with that line of code.
依赖这些细节并不是一个好主意，因为如果不违反使用反射的访问修饰符就无法体验这些细节。该类的所有者只支持普通的公共API，并且可以在将来自由地进行实现更改。
Having said all that the line of code is really very useful when you have a gun held you your head forcing you to do such dangerous things. Using that back door is usually a code smell that you need to upgrade to better library code where you don't have to sin. Another common use of that dangerous line of code is to write a "voodoo framework" (orm, injection container, ...). Many folks get religious about such frameworks (both for and against them) so I will avoid inviting a flame war by saying nothing other than the vast majority of programmers don't have to go there.
