编程语言
首页 > 编程语言> > Java中的String类常用类型

Java中的String类常用类型

作者：互联网

此文来自于plumbr官网，plumbr作为一个常用的JVM 监测工具，官网有完整的oom和gc文章，准备慢慢全部翻译过来：

第一篇：java.lang.OutOfMemoryError: Java heap space

Java 应用程序只允许使用有限的内存量。此限制是在应用程序启动期间指定的。为了让事情变得更复杂，Java 内存被分成两个不同的区域。这些区域称为堆空间和 Permgen（用于永久代）：

这些区域的大小是在 Java 虚拟机 (JVM) 启动期间设置的，可以通过指定 JVM 参数 -Xmx 和 -XX:MaxPermSize 进行自定义。如果您没有明确设置大小，将使用特定于平台的默认值。

该 java.lang.OutOfMemoryError：Java堆空间 时，应用程序错误将被触发 尝试添加更多的数据放入堆空间区域，但没有足够的空间供它 。

请注意，可能有足够的物理内存可用，但是只要 JVM 达到堆大小限制，就会抛出 java.lang.OutOfMemoryError: Java heap space 错误。

1，是什么原因造成的？

java.lang.OutOfMemoryError 的 最常见原因很简单：您尝试将 XXL 应用程序放入 S 大小的 Java 堆空间中。也就是说 - 应用程序只需要比正常运行可用的更多的 Java 堆空间。此 OutOfMemoryError 消息的其他原因更为复杂，并且是由编程错误引起的：

2，举个例子

第一个例子非常简单——下面的 Java 代码尝试分配一个 2M 整数的数组。当您编译它并使用 12MB 的 Java 堆空间 ( java -Xmx12m OOM ) 启动时，它会失败并显示 java.lang.OutOfMemoryError: Java heap space 消息。使用 13MB Java 堆空间，程序运行得很好。

class OOM {
  static final int SIZE=2*1024*1024;
  public static void main(String[] a) {
    int[] i = new int[SIZE];
   }
}

内存泄漏示例

第二个也是更现实的例子是内存泄漏。在 Java 中，当开发人员创建和使用新对象（ 例如 new Integer(5) ）时 ，他们不必自己分配内存——这由 Java 虚拟机 (JVM) 负责。在应用程序的生命周期中，JVM 会定期检查内存中的哪些对象仍在使用，哪些尚未使用。可以丢弃未使用的对象，回收内存并再次使用。这个过程称为 垃圾收集 。JVM 中负责收集的相应模块称为 垃圾收集器 (GC)。

Java 的自动内存管理依赖于 GC 定期查找未使用的对象并删除它们。稍微简化一下，我们可以说 Java 中的 内存泄漏是应用程序不再使用某些对象但 垃圾收集 无法识别它的情况 。结果，这些未使用的对象无限期地保留在 Java 堆空间中。这种堆积最终会触发 java.lang.OutOfMemoryError: Java heap space 错误。

构造一个满足内存泄漏定义的 Java 程序相当容易：

class KeylessEntry {
 
   static class Key {
      Integer id;
 
      Key(Integer id) {
         this.id = id;
      }
 
      @Override
      public int hashCode() {
         return id.hashCode();
      }
   }
 
   public static void main(String[] args) {
      Map m = new HashMap();
      while (true)
         for (int i = 0; i < 10000; i++)
            if (!m.containsKey(new Key(i)))
               m.put(new Key(i), "Number:" + i);
   }
}

当您执行上面的代码时，您可能希望它永远运行而不会出现任何问题，假设朴素的缓存解决方案仅将底层 Map 扩展到 10,000 个元素，因为除此之外，所有键都已经存在于 HashMap 中。然而，实际上这些元素将继续添加，因为 Key 类在其 hashCode() 旁边不包含适当的 equals() 实现。

结果，随着时间的推移，随着不断使用泄漏代码，“缓存”结果最终会消耗大量 Java 堆空间。当泄漏的内存填满堆区域中的所有可用内存并且 垃圾收集 无法清除它时，会抛出 java.lang.OutOfMemoryError:Java 堆空间 。

解决方案很简单——添加类似于下面的 equals() 方法的实现，你会很高兴。但在你找到原因之前，你肯定会失去一些宝贵的脑细胞。

@Override
public boolean equals(Object o) {
   boolean response = false;
   if (o instanceof Key) {
      response = (((Key)o).id).equals(this.id);
   }
   return response;
}

3，解决办法是什么？

在某些情况下，分配给 JVM 的堆数量不足以满足在该 JVM 上运行的应用程序的需求。在这种情况下，你应该只分配更多的堆——请参阅本章末尾以了解如何实现这一点。

然而，在许多情况下，提供更多的 Java 堆空间并不能解决问题。例如，如果您的应用程序包含内存泄漏，添加更多堆只会推迟 java.lang.OutOfMemoryError: Java heap space 错误。此外，增加 Java 堆空间量也往往会增加 GC 暂停 的长度，影响应用程序的 吞吐量或延迟 。

如果您希望解决 Java 堆空间的潜在问题而不是掩盖症状，您需要弄清楚代码的哪一部分负责分配最多的内存。换句话说，您需要回答以下问题：

  1. 哪些对象占据堆的大部分
  2. 在源代码中分配这些对象的位置

此时，请确保在您的日历中清除几天（或 – 请参阅项目符号列表下方的自动方式）。以下是一个粗略的流程大纲，可以帮助您回答上述问题：

或者，我们建议 Plumbr，这是唯一具有自动根本原因检测功能的 Java 监控解决方案 。在其他性能问题中，它捕获所有 java.lang.OutOfMemoryError 并自动为您提供有关最需要内存的数据结构的信息。

Plumbr 负责在幕后收集必要的数据——这包括有关堆使用情况的相关数据（只有对象布局图，没有实际数据），以及一些您甚至在堆转储中都找不到的数据。它还会为您进行必要的数据处理——在 JVM 遇到 java.lang.OutOfMemoryError 时立即进行 。这是来自 Plumbr 的 java.lang.OutOfMemoryError 事件警报示例：

无需任何额外的工具或分析，您就可以看到：

有了这些信息，您就可以放大潜在的根本原因，并确保将数据结构修剪到适合您的内存池的级别。

但是，当您从内存分析或阅读 Plumbr 报告得出的结论是内存使用是合法的并且源代码中没有任何更改时，您需要让您的 JVM 有更多的 Java 堆空间才能正常运行。在这种情况下，更改您的 JVM 启动配置并添加（或增加值，如果存在）以下内容：

-Xmx1024m

上述配置将为应用程序提供 1024MB 的 Java 堆空间。您可以对 GB 使用 g 或 G，对 MB 使用 m 或 M，对 KB 使用 k 或 K。例如，以下所有内容都相当于说最大的 Java 堆空间为 1GB：

java -Xmx1073741824 com.mycompany.MyClass
    java -Xmx1048576k com.mycompany.MyClass
    java -Xmx1024m com.mycompany.MyClass
    java -Xmx1g com.mycompany.MyClass

标签：常用,java,String,应用程序,内存,JVM,OutOfMemoryError,Java
来源： https://blog.csdn.net/zybb166/article/details/122088702