你可能存在内存泄漏或者对你所存储的字符串数据量的理解不正确。我们需要查看更多代码来确定原因。
科学的解决方法是使用内存分析器运行应用程序，并分析输出结果，以确定哪个数据结构使用了意外大量的内存。
如果我要猜测的话，可能是你的应用程序（在某个层次上）正在执行类似以下操作：
String line;
while ((line = br.readLine()) != null) {
// search for tag in line
String tagStr = line.substring(pos1, pos2);
// code as per your example
}
这比你预期的占用了更多的内存。 substring(...) 调用创建一个 tagStr 对象，它引用原始 line 字符串的后备数组。 你期望短小的标签字符串实际上是指保存在原始行中的所有字符的 char[] 对象。
修复方法如下：
String tagStr = new String(line.substring(pos1, pos2));
这将创建一个不共享参数字符串的支持数组的String对象。
更新 - 根据您提供的最新数据，这或类似的解释越来越有可能是正确的。
进一步说明Jon Skeet的观点，一个小字符串的开销惊人地高。例如，在典型的32位JVM上，一个字符的字符串的内存使用情况为:
字符串对象的头部: 2个word
字符串对象字段: 3个word
填充: 1个word (我认为)
支持数组对象的头部: 3个word
支持数组数据: 1个word
总计: 10个word - 40个字节 - 来保存一个 char 数据 ... 或者如果您的输入是在8位字符集中，则为一个 byte 数据。
(这不足以解释您的问题，但您应该注意到它。)