使用这些垃圾收集设置时的JVM性能
我有一个企业级Java应用程序，每天为几千个用户提供服务。这是weblogic 10.3.6（Java1.6 JVM）上的JAXB Web服务，使用Hibernate访问Oracle数据库。它还调用其他Web服务。
我们在生产系统上调整了以下GC设置：
-server -Xms2048m -Xmx2048m -XX:PermSize=512m -XX:MaxPermSize=512m
这种GC分级的效果是什么？硬件有足够的容量来处理它。
我知道这将堆大小和perm-gen设置在一个稳定的水平。但当你最终不得不进行垃圾收集时，这会产生什么影响呢？
在我看来，这似乎会使GC发生的频率降低，但是当它确实发生时需要更长的时间。这听起来正确吗？
共有3个答案
设置-Xmx
-server将允许JVM使用服务器编译器，这将在将代码编译为本机程序集指令之前进行更积极的优化。尽管现在任何具有2个或更多内核和2GB内存的机器都默认启用服务器编译器。
增加内存并不总能解决问题。有时添加更多的内存会是一种开销。
如果您需要有关GC的详细信息，可以尝试此链接。
调整某些内容的真正原因是通过实现吞吐量和延迟目标来提高应用程序的性能。
这将使气相色谱发生的频率降低，但当它发生时需要更长的时间
可能，这取决于您的用例。您甚至可能会发现GC在极少数情况下更短。
2 GB的堆并不算多，我会使用高达26 GB的堆，而不用担心堆的大小。超过这个大小，内存访问会稍微慢一点或者使用更多的内存。
我会说，请在决定大小之前监控GC，因为您永远不知道应用程序在负载下的行为。看看这个链接，它有一些关于GC的很好的参考资料和计算工具。
-
每个java开发人员都知道，java对象不再使用时将被垃圾收集。我想知道JVM如何识别必须为垃圾收集选择的对象。（例如，如果我有10个对象。如果对10个对象中的2个进行垃圾收集，jvm将如何找到这两个对象）。 JVM使用标记和扫描算法（如果我是对的）。 1）例如我在下面提供字符串对象场景 //现在s1
-
一、垃圾收集算法 1.标记-清除算法 最基础的收集算法是“标记-清除”（Mark-Sweep）算法，如同它的名字一样，算法分为“标记”和“清除”两个阶段。 ①首先标记出所有需要回收的对象 ②在标记完成后统一回收所有被标记的对象。 不足： 效率问题：标记和清除两个过程的效率都不高 空间问题：标记清除之后产生大量不连续的内存碎片，空间碎片太多可能会导致以后程序运行过程中需要分配较大对象时，无法找到足够
-
问题内容： 我有一段代码可以在内存中加载很大的图像。所以打电话似乎是合理的事情 在加载图像之前。据我所知，它毫无问题。 昨天，我决定使用一个名为FindBugs的非常有用的软件来扫描您的代码并报告可能导致错误或通常不建议使用的策略的问题。问题是我提到的这段代码得到了报告。描述是这样的： …强迫垃圾收集；除了基准测试代码外，都非常可疑 并继续阐述： 代码显式调用垃圾回收。除了基准测试中的特定用途外，
-
我正在做一个与JVM GC相关的项目，我计划用我的手动GC取代JVM自动GC。 我知道JAVA有一个自动垃圾收集器。如果我们集成一个新的手动垃圾收集器，其中开发人员需要显式地调用new并删除对象（如在C中）。 让我们假设程序员在没有内存泄漏的情况下写入空闲。 使用手动垃圾回收机制代替自动垃圾回收机制是否有效？ 在工业中使用手动GC是否常见？还是程序员到处使用自动垃圾回收器？
-
如果我错了，请随时指正。在JVM堆中，有老一代和年轻一代两代。在做全GC时，在老一代中，有像紧凑空间和修复漏洞这样的繁重操作，这会使JVM挂起。而我发现在年轻一代中，应用了一个轻量级的GC，从我的搜索结果中还有一个叫做Eden的区域涉及年轻一代。但是，在搜索了很多文档后，我对年轻一代中的GC仍然有两个困惑， 在年轻一代中，GC似乎不像老一代GC那样工作（即老一代GC压缩并修复漏洞）？如果是这样，年
-
Kubernetes 垃圾收集器的角色是删除指定的对象，这些对象曾经有但以后不再拥有 Owner 了。 注意：垃圾收集是 beta 特性，在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如，一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner