为什么 GC 不在同一个方法中 运行
Why GC doesn't run within the same method
我正在玩 gc，发现不涉及 gc（我使用并行 gc）时的有趣情况
这是我的代码
public static void main(String[] args) {
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
String[] strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
}
我的 Java 版本是：
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
此程序涉及以下 argc：
-Xmx64m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
这是输出：
59 free
10485760
19 free
2019-06-09T14:53:18.868+0600: 0.105: [GC (Allocation Failure) [PSYoungGen: 1640K->480K(18944K)] 42600K->41448K(62976K), 0.0018199 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.870+0600: 0.107: [Full GC (Ergonomics) [PSYoungGen: 480K->0K(18944K)] [ParOldGen: 40968K->41339K(44032K)] 41448K->41339K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0174681 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]
2019-06-09T14:53:18.888+0600: 0.125: [GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] 41339K->41339K(62976K), 0.0017270 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.889+0600: 0.126: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] [ParOldGen: 41339K->41321K(44032K)] 41339K->41321K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0140842 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
Heap
PSYoungGen total 18944K, used 491K [0x00000000feb00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 3% used [0x00000000feb00000,0x00000000feb7afa0,0x00000000ffb00000)
from space 2560K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x0000000100000000)
to space 2560K, 0% used [0x00000000ffb00000,0x00000000ffb00000,0x00000000ffd80000)
ParOldGen total 44032K, used 41321K [0x00000000fc000000, 0x00000000feb00000, 0x00000000feb00000)
object space 44032K, 93% used [0x00000000fc000000,0x00000000fe85a6d0,0x00000000feb00000)
Metaspace used 3064K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 336K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at lightbox.GcWIthoutComp.main(GcWIthoutComp.java:11)
根据日志，JVM 无法第二次为字符串分配内存，但如果我添加 JVM arg -Xcomp，它将工作并提供此输出
59 free
10485760
19 free
2019-06-09T15:01:06.593+0600: 0.830: [GC (Allocation Failure) [PSYoungGen: 1982K->512K(18944K)] 42942K->41480K(62976K), 0.0008554 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
2019-06-09T15:01:06.594+0600: 0.831: [Full GC (Ergonomics) [PSYoungGen: 512K->0K(18944K)] [ParOldGen: 40968K->411K(37376K)] 41480K->411K(56320K), [Metaspace: 3377K->3377K(1056768K)], 0.0100865 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
10485760
20 free
Heap
PSYoungGen total 18944K, used 1147K [0x00000000feb00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 7% used [0x00000000feb00000,0x00000000fec1ed48,0x00000000ffb00000)
from space 2560K, 0% used [0x00000000ffb00000,0x00000000ffb00000,0x00000000ffd80000)
to space 2560K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x0000000100000000)
ParOldGen total 44032K, used 41371K [0x00000000fc000000, 0x00000000feb00000, 0x00000000feb00000)
object space 44032K, 93% used [0x00000000fc000000,0x00000000fe866c90,0x00000000feb00000)
Metaspace used 3399K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 334K, capacity 388K, committed 512K, reserved 1048576K
据我了解，就检测未使用的内存而言，编译后的代码对于 GC 来说非常方便。
此外，如果我删除 -Xcomp 并将数组创建移动到单独的方法，它不会抛出 OOM 异常：
public static void main(String[] args) {
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
allocate();
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
allocate();
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
}
private static void allocate() {
String[] strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
}
我的问题是：
为什么-Xcomp 解决了如上所示的分配问题？
为什么将分配移动到单独的方法解决了我的问题？
如果您有有用的链接，请在评论中提供。
评论只占一行，很难解释清楚。重要的区别似乎是，使用 -Xcomp，局部变量字符串已经可以收集了。所以你得到：
2019-06-09T15:01:06.593+0600: 0.830: [GC (Allocation Failure) [PSYoungGen: 1982K->512K(18944K)] 42942K->41480K(62976K), 0.0008554 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
2019-06-09T15:01:06.594+0600: 0.831: [Full GC (Ergonomics) [PSYoungGen: 512K->0K(18944K)] [ParOldGen: 40968K->411K(37376K)] 41480K->411K(56320K), [Metaspace: 3377K->3377K(1056768K)], 0.0100865 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
因此您遇到分配失败，但 GC 可以释放足够的内存。
如果没有 -Xcomp，则无法收集 loal 变量字符串，因此您收到的消息类似于：
2019-06-09T14:53:18.868+0600: 0.105: [GC (Allocation Failure) [PSYoungGen: 1640K->480K(18944K)] 42600K->41448K(62976K), 0.0018199 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.870+0600: 0.107: [Full GC (Ergonomics) [PSYoungGen: 480K->0K(18944K)] [ParOldGen: 40968K->41339K(44032K)] 41448K->41339K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0174681 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]
2019-06-09T14:53:18.888+0600: 0.125: [GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] 41339K->41339K(62976K), 0.0017270 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.889+0600: 0.126: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] [ParOldGen: 41339K->41321K(44032K)] 41339K->41321K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0140842 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
这表明 GC 尝试释放内存但无法释放内存。
（查看 PSYoungGen：它显示了内存是如何下降的。当它在没有 -Xcomp 的情况下失败时，几乎不可能。使用 -Xcomp 它从 1982K 下降到 512K。另见 https://dzone.com/articles/understanding-garbage-collection-log）
我无法找到 -Xcomp 正在做的确切内容。所以很抱歉，我现在只能给你日志的解释。
所以这就像在分配新生成的数组之前将字符串设置为 null。
所以如果你添加一个 strings = null;在第二次分配数组之前：即使没有 -Xcomp，您也会或多或少地得到与 gc.
相同的消息
关于在方法中使用它：
您的方法中有一个局部变量。所以你分配数组然后方法结束，局部变量可以被垃圾收集器收集。
我正在玩 gc，发现不涉及 gc（我使用并行 gc）时的有趣情况 这是我的代码
public static void main(String[] args) {
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
String[] strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
}
我的 Java 版本是：
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
此程序涉及以下 argc：
-Xmx64m -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps
这是输出：
59 free
10485760
19 free
2019-06-09T14:53:18.868+0600: 0.105: [GC (Allocation Failure) [PSYoungGen: 1640K->480K(18944K)] 42600K->41448K(62976K), 0.0018199 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.870+0600: 0.107: [Full GC (Ergonomics) [PSYoungGen: 480K->0K(18944K)] [ParOldGen: 40968K->41339K(44032K)] 41448K->41339K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0174681 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]
2019-06-09T14:53:18.888+0600: 0.125: [GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] 41339K->41339K(62976K), 0.0017270 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.889+0600: 0.126: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] [ParOldGen: 41339K->41321K(44032K)] 41339K->41321K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0140842 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
Heap
PSYoungGen total 18944K, used 491K [0x00000000feb00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 3% used [0x00000000feb00000,0x00000000feb7afa0,0x00000000ffb00000)
from space 2560K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x0000000100000000)
to space 2560K, 0% used [0x00000000ffb00000,0x00000000ffb00000,0x00000000ffd80000)
ParOldGen total 44032K, used 41321K [0x00000000fc000000, 0x00000000feb00000, 0x00000000feb00000)
object space 44032K, 93% used [0x00000000fc000000,0x00000000fe85a6d0,0x00000000feb00000)
Metaspace used 3064K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 336K, capacity 388K, committed 512K, reserved 1048576K
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at lightbox.GcWIthoutComp.main(GcWIthoutComp.java:11)
根据日志，JVM 无法第二次为字符串分配内存，但如果我添加 JVM arg -Xcomp，它将工作并提供此输出
59 free
10485760
19 free
2019-06-09T15:01:06.593+0600: 0.830: [GC (Allocation Failure) [PSYoungGen: 1982K->512K(18944K)] 42942K->41480K(62976K), 0.0008554 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
2019-06-09T15:01:06.594+0600: 0.831: [Full GC (Ergonomics) [PSYoungGen: 512K->0K(18944K)] [ParOldGen: 40968K->411K(37376K)] 41480K->411K(56320K), [Metaspace: 3377K->3377K(1056768K)], 0.0100865 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
10485760
20 free
Heap
PSYoungGen total 18944K, used 1147K [0x00000000feb00000, 0x0000000100000000, 0x0000000100000000)
eden space 16384K, 7% used [0x00000000feb00000,0x00000000fec1ed48,0x00000000ffb00000)
from space 2560K, 0% used [0x00000000ffb00000,0x00000000ffb00000,0x00000000ffd80000)
to space 2560K, 0% used [0x00000000ffd80000,0x00000000ffd80000,0x0000000100000000)
ParOldGen total 44032K, used 41371K [0x00000000fc000000, 0x00000000feb00000, 0x00000000feb00000)
object space 44032K, 93% used [0x00000000fc000000,0x00000000fe866c90,0x00000000feb00000)
Metaspace used 3399K, capacity 4500K, committed 4864K, reserved 1056768K
class space used 334K, capacity 388K, committed 512K, reserved 1048576K
据我了解，就检测未使用的内存而言，编译后的代码对于 GC 来说非常方便。 此外，如果我删除 -Xcomp 并将数组创建移动到单独的方法，它不会抛出 OOM 异常：
public static void main(String[] args) {
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
allocate();
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
allocate();
System.out.println(Runtime.getRuntime().freeMemory() / (1024 * 1024) + " free");
}
private static void allocate() {
String[] strings = new String[(40 * 1024 * 1024) / Integer.BYTES];
System.out.println(strings.length);
}
我的问题是：
为什么-Xcomp 解决了如上所示的分配问题？
为什么将分配移动到单独的方法解决了我的问题？
如果您有有用的链接，请在评论中提供。
评论只占一行，很难解释清楚。重要的区别似乎是，使用 -Xcomp，局部变量字符串已经可以收集了。所以你得到：
2019-06-09T15:01:06.593+0600: 0.830: [GC (Allocation Failure) [PSYoungGen: 1982K->512K(18944K)] 42942K->41480K(62976K), 0.0008554 secs] [Times: user=0.01 sys=0.00, real=0.00 secs]
2019-06-09T15:01:06.594+0600: 0.831: [Full GC (Ergonomics) [PSYoungGen: 512K->0K(18944K)] [ParOldGen: 40968K->411K(37376K)] 41480K->411K(56320K), [Metaspace: 3377K->3377K(1056768K)], 0.0100865 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
因此您遇到分配失败，但 GC 可以释放足够的内存。
如果没有 -Xcomp，则无法收集 loal 变量字符串，因此您收到的消息类似于：
2019-06-09T14:53:18.868+0600: 0.105: [GC (Allocation Failure) [PSYoungGen: 1640K->480K(18944K)] 42600K->41448K(62976K), 0.0018199 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.870+0600: 0.107: [Full GC (Ergonomics) [PSYoungGen: 480K->0K(18944K)] [ParOldGen: 40968K->41339K(44032K)] 41448K->41339K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0174681 secs] [Times: user=0.04 sys=0.00, real=0.02 secs]
2019-06-09T14:53:18.888+0600: 0.125: [GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] 41339K->41339K(62976K), 0.0017270 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
2019-06-09T14:53:18.889+0600: 0.126: [Full GC (Allocation Failure) [PSYoungGen: 0K->0K(18944K)] [ParOldGen: 41339K->41321K(44032K)] 41339K->41321K(62976K), [Metaspace: 3033K->3033K(1056768K)], 0.0140842 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
这表明 GC 尝试释放内存但无法释放内存。
（查看 PSYoungGen：它显示了内存是如何下降的。当它在没有 -Xcomp 的情况下失败时，几乎不可能。使用 -Xcomp 它从 1982K 下降到 512K。另见 https://dzone.com/articles/understanding-garbage-collection-log）
我无法找到 -Xcomp 正在做的确切内容。所以很抱歉，我现在只能给你日志的解释。 所以这就像在分配新生成的数组之前将字符串设置为 null。 所以如果你添加一个 strings = null;在第二次分配数组之前：即使没有 -Xcomp，您也会或多或少地得到与 gc.
相同的消息关于在方法中使用它： 您的方法中有一个局部变量。所以你分配数组然后方法结束，局部变量可以被垃圾收集器收集。