Question

最近有一个过程我们正在努力消耗比预期更多的内存。在检查堆时，创建了很多print (X) Datetime CLASS label 0 2010-03-12 16:35:00 0 0 1 2010-03-12 16:36:00 0 0 2 2010-03-12 16:37:00 0 0 3 2010-03-12 16:38:00 0 0 4 2010-03-12 16:39:00 1 1 5 2010-03-12 16:40:00 1 1 6 2010-03-12 16:41:00 1 1 7 2010-03-12 16:42:00 1 1 8 2010-03-12 16:43:00 1 1 9 2010-03-12 16:44:00 1 1 10 2010-03-12 16:45:00 1 1 11 2010-03-12 16:46:00 1 1 12 2010-03-12 16:47:00 1 1 13 2010-03-12 16:48:00 1 1 14 2010-03-12 16:49:00 nan 2 15 2010-03-12 16:50:00 nan 2 16 2010-03-12 16:51:00 nan 2 17 2010-03-12 16:52:00 nan 2 18 2010-03-12 16:53:00 nan 2 19 2010-03-12 16:54:00 nan 2 20 2010-03-12 16:55:00 nan 2 21 2010-03-12 16:56:00 nan 2 22 2010-03-12 16:57:00 nan 2 23 2010-03-12 16:58:00 nan 2 24 2010-03-12 16:59:00 nan 2 25 2010-03-12 17:00:00 nan 2 26 2010-03-12 17:01:00 2 2 27 2010-03-12 17:02:00 2 2 28 2010-03-12 17:03:00 2 2 29 2010-03-12 17:04:00 2 2。这可以解释，因为我们将一些数据存储在以java.util.LocalTime为关键字的时间图中。与预期相比，上游产生的数据可能太多了。

然而，令人惊讶的是，还创建了许多LocalTime。我们不使用这门课;它会由sun.util.calendar.ZoneInfo生成吗？但是，如果我们检查LocalTime的源代码，我就不会看到使用java.time.LocalTime;有没有人对此有所了解？

Answer 1

很抱歉迟到的答案，但现在我已经找到时间检查JDK来源。

如果您致电LocalTime.now()，则java.time将使用系统时区（隐式相关性）。

public static LocalTime now() {
    return now(Clock.systemDefaultZone());
}

然后Clock加载ZoneId.systemDefault()：

public static Clock systemDefaultZone() {
    return new SystemClock(ZoneId.systemDefault());
}

最后，类java.util.TimeZone用于查找默认区域。

public static ZoneId systemDefault() {
    return TimeZone.getDefault().toZoneId();
}

如果你查看TimeZone.getDefault()的来源，那么你会在堆栈的某个深度看到：

private static TimeZone getTimeZone(String ID, boolean fallback) {
    TimeZone tz = ZoneInfo.getTimeZone(ID);
    if (tz == null) {
        tz = parseCustomTimeZone(ID);
        if (tz == null && fallback) {
            tz = new ZoneInfo(GMT_ID, 0);
        }
    }
    return tz;
}

Voilá，班级sun.util.calendar.ZoneInfo也将加载。

创建java.time.LocalTime也会触发sun.util.calendar.ZoneInfo的创建

1 个答案: