我在glassfish服务器上部署了一个Web应用程序，它只包含一堆JAX-RS REST服务和通过JPA处理数据库。我用于部署的WAR文件大约是2MB，它的流量非常少（只有几个测试请求）。出于好奇，我运行了一个jmap来查看内存使用情况，我得到了这个
using thread-local object allocation.
Parallel GC with 2 thread(s)
Heap Configuration:
MinHeapFreeRatio = 0
MaxHeapFreeRatio = 100
MaxHeapSize = 536870912 (512.0MB)
NewSize = 1310720 (1.25MB)
MaxNewSize = 17592186044415 MB
OldSize = 5439488 (5.1875MB)
NewRatio = 2
SurvivorRatio = 8
PermSize = 21757952 (20.75MB)
MaxPermSize = 201326592 (192.0MB)
G1HeapRegionSize = 0 (0.0MB)
Heap Usage:
PS Young Generation
Eden Space:
capacity = 99090432 (94.5MB)
used = 36256552 (34.576942443847656MB)
free = 62833880 (59.923057556152344MB)
36.589357083436674% used
From Space:
capacity = 38797312 (37.0MB)
used = 13067872 (12.462493896484375MB)
free = 25729440 (24.537506103515625MB)
33.68241593644426% used
To Space:
capacity = 37748736 (36.0MB)
used = 0 (0.0MB)
free = 37748736 (36.0MB)
0.0% used
PS Old Generation
capacity = 70254592 (67.0MB)
used = 59577728 (56.8177490234375MB)
free = 10676864 (10.1822509765625MB)
84.80261048274254% used
PS Perm Generation
capacity = 135266304 (129.0MB)
used = 88929544 (84.80982208251953MB)
free = 46336760 (44.19017791748047MB)
65.74404812598414% used
我很惊讶地发现Perm Gen为这么小的应用程序需要大约84MB的内存。当我重新启动服务器时，这个数字下降了（之前就像100MB一样，因为我读过perm gen永远不会被垃圾收集，所以看起来很奇怪，所以怎么会掉下来？）。我的疑问是：用如此小的应用获得如此高的数字是否正常？在过去的几周里，我实际上已经多次部署和重新部署了应用程序，那么可能是由于这个原因吗？ 该应用程序运行良好，所以我没有特别的问题需要解决，我只是想知道这是否会导致将来出现问题。即使是Eden空间的数量对我来说也很重要，34MB用于目前只有一个用户的应用程序，数据库是空的，基本上没什么相关的！
编辑：我现在取消部署应用程序并重新启动服务器（现在在不同的pid下运行）。令我惊讶的是，我运行了另一个jmap，我得到了非常相似的perm gen数字（就像70MB一样）。这可能与glassfish有关，它与我的应用程序无关吗？
答案 0 :(得分：0)
Perm Gen的一个问题是静态的东西。静态分配来自Perm Gen，但在重新启动容器（Glassfish，Tomcat，...）之前不会释放。
如果静态指向另一个类（即使该类不是静态的），那么另一个类也将永远不会释放。如果在不重新启动容器的情况下重新启动应用程序，则不会释放该类的内存，并且将为该应用程序的新实例分配该类的另一个实例。
许多类都有指向其他类的静态指针。您可以尝试消除代码中的问题，但许多Java类都存在此问题，因此可能无法控制。
以下是关于此主题的优秀文章：Classloader Leaks。
回应Glassfish评论：
是的，可能是由于Glassfish。每个班级都分配给了Perm Gen，所以很多班级意味着很多Perm Gen.即使你的班级很小，它也站在巨人的肩膀上。