blocks|key|2355062|text|PermGen将增长到预定的最大值(您可以从命令行设置这个最大值)，然后停止。PermGen区域主要保存类定义，通常在加载大量类而不发布类的应用程序中耗尽PermGen+--要么是因为它们很大，要么是因为在web应用程序中，在类加载器发布后，有东西意外地抓住了一个类。您需要确定PermGen是否持续增长，还是最终稳定下来。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2355063|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

PermGen will grow up to a predetermined maximum (which you can set from the command line) and then stop. The PermGen area holds primarily class definitions, and usually you run out of PermGen in applications that load a lot of classes and don't release them -- either because they're just big or, in web apps, because something is accidentally holding on to a class after its classloader has been released. You need to determine whether PermGen keeps growing and growing, or whether it eventually stabilizes.

blocks|key|2714705|text|PermGen空间在应用程序代码或正在使用的库中使用随着时间的推移，可能会出现某些内存泄漏/错误。。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2714706|例如，在Apache中运行webapp时经常会出现问题，如果webapp实例被重新加载太多次，则使用Spring和log4j，显然log4j存在一些问题，它不能正确地从类加载器卸载某些类。|2714707|因此，确实有可能出现导致PermGen空间随时间增长的泄漏，就像正常的内存泄漏一样。|2714708|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java^0|Q|N|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|U|8|@]|9|@]|C|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

PermGen space used <a href="http://blogs.oracle.com/fkieviet/entry/classloader_leaks_the_dreaded_java" rel="nofollow">may grow over time to certain memory leaks / bugs</a> in the application code, or in the libraries you are using.

For example we frequently see problems when running a webapp in Apache Tomcat which uses Spring and log4j if the webapp instance is reloaded too many times, apparently log4j has some issues where it does not properly unload certain classes from the classloader.

So yes, it is possible to have leaks that cause PermGen space to grow over time, just like normal memory leaks.

blocks|key|2714608|text|你的推理有点不清楚。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2714609|如果您预期会失败，为什么不立即采取防御性方法并增加-XX:MaxPermSize呢？|offset|length|style|CODE|2714610|entityMap^0|0|P|F|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Your reasoning is a little unclear. 

If you anticipate a failure, why not take the defensive approach and increase the <code>-XX:MaxPermSize</code> right away?

blocks|key|2355160|text|我们注意到，我们的客户运行Solaris+10的永久GC从50%25增长到97%25的容量。|type|blockquote|depth|inlineStyleRanges|entityRanges|data|2355161|在您的客户的应用程序中是否有显着的代码更改，然后才注意到perm+gen的激增？还是一直是这样(从50%25到97%25)？|unstyled|2355162|我想这一点并不重要，但在某些情况下，在系统测试期间应该可以检测到这样的尖峰(假设您的团队在客户的系统测试周期中具有可见性)。|2355163|有一件事可以肯定的是，以97%25的速度运行对于舒适度来说太接近最大值了，而且您将不得不使用max+perm+gen参数(因此也可以使用其他堆参数.最有可能)|2355164|这个JVM使用的是默认值"+Permgen“(我们没有向JVM传递任何自定义Permgen标志)。|2355165|不是个好主意。在部署之前，您应该(必须阅读)始终对您(或您的客户)应用程序进行描述。或者您的客户应该告诉您他们需要什么参数，或者您的团队必须在UAT和系统测试周期中确定这些参数(假设您对这些参数具有可见性，请参见上文)。|2355166|我们是否应该认为，短期内，它可以做一个OutOfMemoryError？|2355167|这并不是不可避免的，但这是一种可能性(特别是如果应用程序还没有受到最大可能的负载)。如果尖峰是最近出现的现象，这也是可能的。在这种情况下，很可能是由于代码更改，或由于其他因素(操作系统中的修补程序、容器中的修补程序、客户流量的变化、db中的更改等)而造成的。|2355168|与其在生产中运行97%25的permgen空间，不如设置一个更高的PermGen值吗？|2355169|海事组织是的。如果您(或您的客户)能够描述或估计应用程序的内存(包括perm和堆)需求(以及当前和未来可能的流量)，您应该给自己10%25-20%25的利润率，以防万一。没什么不过是玩火而已。任何更有可能的事情都是浪费的。|2355170|内存可能很便宜，但应用程序的性能和稳定性却并非如此;)|2355171|如果你没有使用可视化，你应该使用。它是一个很好的工具，可以直观地检查JVM内存中不同段的运行情况。也有可视化，这是更强大和通用的，然而，可视化UI的阅读方式是特别适合这项任务。|2355172|P.S+:我们在solaris+10上使用JDK+1.6.0_23。|2355173|我不认为那应该重要。您的应用程序容器是什么(如果您的应用程序在其中运行)。您可能需要编辑您的帖子以包括此内容。|2355174|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|15|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|16|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|17|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|D|7|19|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|1A|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|D|7|1D|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1E|8|@]|9|@]|A|$]]|$1|W|3|X|5|D|7|1F|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1G|8|@]|9|@]|A|$]]|$1|10|3|11|5|D|7|1H|8|@]|9|@]|A|$]]|$1|12|3|-4|5|D|7|1I|8|@]|9|@]|A|$]]]|13|$]]

<blockquote>
 We are noticing that our customer
 running Solaris 10 is having Permanent
 GC grow from 50% to 97% of capacity.
</blockquote>

Was there a significant code change in your customer's application prior to noticing the spike in perm gen? Or has it always been like this (going from 50% to 97%)?

I guess it doesn't really matter at this point, but in some cases, spikes like this should be detectable during system testing (assuming your team has visibility in your customers' system testing cycle.)

One thing for certain is that running at 97% is way too much close to the max for comfort, and you will have to play with the max perm gen parameters (and as a consequence with other heap parameters... most likely.)

<blockquote>
 This JVM was using the default value
 of "permgen" (we did NOT pass any
 custom Permgen FLAG to the JVM).
</blockquote>

Not a good idea. You should (read must) always characterize your (or your customers) applications before deployment. Either your customers should tell you what params they need, or your team must determine those during UAT and system test cycles (assuming you have visibility on those; see above.)

<blockquote>
 Should we think that anytime soon, it could do a OutOfMemoryError ?
</blockquote>

It is not an inevitability, but it is a possibility (especially if the app has not been subjected to the max possible load yet.) It is also possible if the spike is a recent phenomenon. In that case, due, most likely, to a code change, or a previously unknown condition due to other factors (a patch in the OS, in the container, change in customer traffic, change in the db, etc.)

<blockquote>
 Instead of running at 97% permgen
 space in production, should we set a
 higher value of PermGen ?
</blockquote>

IMO, yes. If you (or your customer) can characterize or estimate the app's memory (both perm and heap) requirements (as well as current and possible future traffic), you should give yourself a 10%-20% margin, just in case. Anything less is just playing with fire. Anything more most likely will be wasteful. 

Memory might be cheap, but application performance and stability are not ;)

If you haven't use visualgc, you should. It's a good tool to visually inspect what's going with the different segments in your JVM memory. There is also visualvm, which is more powerful and versatile, yet, the visualgc UI presentation of readings is specifically suitable for this task.

<blockquote>
 P.S : we're using JDK 1.6.0_23 on
 solaris 10.
</blockquote>

I don't think that should matter. What is your application container (if your app is running in one.) You might want to edit your post to include this.

blocks|key|2355194|text|我相信JVM将使用与普通堆相同的策略来扩展permgen堆。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2355195|permgen堆大小从可配置的初始大小开始。|unordered-list-item|2355196|如果使用的permgen堆与permgen堆大小的比率大于permgen收集后的给定值，则将对其进行扩展。|2355197|permgen堆大小可能会增长到可配置的最大大小。|2355198|现在，如果在GC之后permgen堆已经满了97%25，那么permgen很可能已经扩展到配置的最大大小(在您的情况下是默认的)。|2355199|我们不可能知道OOME在哪里即将到来。(这取决于您的应用程序的行为方式，以及是什么导致它增加了permgen的使用。)然而，谨慎的做法是：|2355200|在短期内增加更大的最大permgen堆大小|2355201|跟踪导致permgen堆使用增加的原因。|2355202|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$]]|$1|E|3|F|5|D|7|U|8|@]|9|@]|A|$]]|$1|G|3|H|5|D|7|V|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|W|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Y|8|@]|9|@]|A|$]]|$1|O|3|P|5|D|7|Z|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|R|$]]

I believe that the JVM will use the same strategy for expanding the permgen heap as it does with the normal heap.

<ul>
<li>The permgen heap size starts at a configurable initial size</li>
<li>If the ratio of used permgen heap to permgen heap size is greater than a given value after a permgen collection, it will be expanded.</li>
<li>The permgen heap size may grow to a configurable maximum size</li>
</ul>

Now if the permgen heap is 97% full after GC, then it is highly likely that permgen has already been expanded to the maximum size configured (the default in your case).

It is impossible to say where an OOME is imminent. (It depends on how your application behaves, and what is causing it to increase permgen usage.) However, it would be prudent to:

<ul>
<li>increase a larger maximum permgen heap size in the short term, and</li>
<li>track down what is causing increased permgen heap usage.</li>
</ul>

blocks|key|2355098|text|有一个最大的PermGen大小，当这个si到达时，您将得到一个OutOfMemoryError。但是，如果您已经满了97%25，这并不意味着您处于最大值，仅为当时分配空间的97%25。(在另外3%25的情况下，它将不得不扩大空间，如果可以的话)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2355099|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

There is a maximum PermGen size and you get an OutOfMemoryError when this si reached. However if you are 97% full it doesn't mean you are at your maximum, just 97% of the space allocated at that time. (In another 3% it will have to grow the space if it can)

we are noticing that our customer running Solaris 10 is having Permanent GC grow from 50% to 97% of capacity. This JVM was using the default value of "permgen" (we did NOT pass any custom Permgen FLAG to the JVM).

Instead of running at 97% permgen space in production, should we set a higher value of PermGen ?

P.S : we're using JDK 1.6.0_23 on solaris 10.

UPDATE
Should we think that anytime soon, it could do a OutOfMemoryError ? OR is it possible that the JVM will increase capacity so that the usage falls below 97% ?

Permanent Generation : does the capacity of default value get fixed or will it grow as required?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我们注意到，我们的客户运行Solaris 10的永久GC从50%增长到97%的容量。这个JVM使用的是默认值" Permgen“(我们没有向JVM传递任何自定义Permgen标志)。与其在生产中运行97%的permgen空间，不如设置一个更高的PermGen值吗？P.S :我们在solaris 10上使用JDK 1.6.0_23。UPDATE我们应该认为它很快就可以做OutOfMemoryErro

问永久一代:默认值的容量是固定的还是会根据需要增长？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问永久一代:默认值的容量是固定的还是会根据需要增长？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问永久一代:默认值的容量是固定的还是会根据需要增长？
EN