简单明了的答案是因为char[]是可变的，而String对象不是可变的。

Java中的字符串是不可变的对象。这就是为什么它们一旦创建就不能被修改，因此从内存中删除它们的内容的唯一方法就是垃圾收集。只有当对象释放的内存可以被覆盖时，数据才会消失。

现在，Java中的垃圾收集不会在任何保证的时间间隔内发生。因此，字符串可以在内存中保存很长时间，如果在此期间进程崩溃，字符串的内容可能会在内存转储或某些日志中结束。

使用字符数组，您可以读取密码，尽快完成处理，然后立即更改内容。

前面的很多答案都很好。还有一点我在假设（如果我错了，请纠正我）。

默认情况下，Java使用UTF-16存储字符串。使用字符数组、char[]数组，有助于使用Unicode、区域字符等。该技术允许所有字符集在存储密码时受到同等尊重，因此不会因字符集混淆而引发某些加密问题。最后，使用字符数组，我们可以将密码数组转换为所需的字符集字符串。

我认为这不是一个有效的建议，但是，我至少可以猜出原因。

我认为动机是希望确保在密码被使用后，您可以及时且确定地删除记忆中的所有密码痕迹。使用char[]，您可以用空白或确定的内容覆盖数组的每个元素。不能这样编辑字符串的内部值。

但这并不是一个好答案；为什么不确保对char[]或String的引用不转义？那么就没有安全问题了。但问题是，String对象在理论上可以被内部化，并在常量池中保持活动状态。我想使用char[]禁止这种可能性。

引用一份官方文档，Java Cryptography Architecture指南介绍了char[]与String密码（关于基于密码的加密，但这更一般地是关于密码）：

将密码收集并存储在对象中似乎是合乎逻辑的然而，这里有一个警告：类型String是不可变的，即没有定义允许您更改（覆盖）或清零字符串的内容使用后。此功能使字符串对象不适合存储诸如用户密码之类的安全敏感信息。你应始终在char数组。

Java编程语言4.0版安全编码指南2-2也提到了类似的内容（尽管最初是在日志记录的上下文中）：

准则2-2：不记录高度敏感信息一些信息，如社会安全号码（SSN）和密码是高度敏感的。此信息不应保留无论在什么地方，甚至在管理员。例如，不应将其发送到日志文件和它的存在不应该通过搜索来检测。一些瞬态数据可以保存在可变数据结构中，例如char数组，以及使用后立即清除。清除数据结构减少了当对象移入时，在典型的Java运行时系统上的有效性存储器对程序员来说是透明的。本指南还对实施和使用没有数据语义知识的低级库他们正在处理。例如，低级字符串解析库可以记录其工作的文本。应用程序可以解析SSN与图书馆。这会导致SSN管理员可以访问日志文件。

字符串是不可变的。这意味着一旦创建了String，如果另一个进程可以转储内存，那么在垃圾收集开始之前，就没有办法（除了反射之外）清除数据。

使用数组，您可以在完成后显式擦除数据。您可以用任何您喜欢的内容覆盖数组，并且密码不会出现在系统中的任何位置，甚至在垃圾收集之前。

是的，这是一个安全问题，但即使使用char[]也只会减少攻击者的机会窗口，而且只针对这种特定类型的攻击。

如注释中所述，垃圾收集器移动的数组可能会在内存中留下数据的零散副本。我认为这是特定于实现的——垃圾收集器可以在运行时清除所有内存，以避免这种情况。即使这样，char[]仍有一段时间包含实际字符作为攻击窗口。

答案已经给出了，但我想与大家分享一下我最近在Java标准库中发现的一个问题。尽管他们现在非常小心地将密码字符串替换为随处可见的char[]（这当然是一件好事），但在从内存中清除密码时，其他安全关键数据似乎被忽略了。

我正在考虑例如PrivateKey类。考虑一个场景，您将从PKCS#12文件加载一个专用RSA密钥，并使用它执行一些操作。现在，在这种情况下，只要对密钥文件的物理访问受到适当限制，单独嗅探密码对您没有多大帮助。作为一名攻击者，如果您直接获得密钥而不是密码，您的情况会更好。所需的信息可能是多方面的泄漏，核心转储、调试器会话或交换文件只是一些示例。

事实证明，没有任何东西可以让您从内存中清除PrivateKey的私有信息，因为没有API可以让您擦除构成相应信息的字节。

这是一个糟糕的情况，因为本文描述了这种情况如何被潜在利用。

例如，OpenSSL库在释放私钥之前会覆盖关键内存段。由于Java是垃圾收集的，所以我们需要显式方法来清除Java密钥的私有信息并使其无效，这些私有信息将在使用密钥后立即应用。