I know how to set the Java heap size in Tomcat and Eclipse. My question is why? Was there an arbitrary limit set on the initial heap back when Java was first introduced so the VM wouldn't grow over a certain size? It seems with most machines today with large memory space available this isn't something we should have to deal with.
Thanks, Tom
我知道如何在Tomcat和Eclipse中设置Java堆大小。我的问题是为什么?在Java首次引入时,是否在初始堆上设置了任意限制,因此VM不会增长到一定的大小?现在大多数机器似乎都有大量的内存空间,这不是我们应该处理的事情。谢谢,汤姆
4 个解决方案
#1
Even now, the heap doesn't grow without limit.
即使是现在,堆也不会无限制地增长。
When the oldest generation is full, should you expand it or just GC? Or should you only expand it if a GC doesn't free any memory?
当最老一代已满时,您应该扩展它还是仅仅GC?或者,如果GC没有释放任何内存,您是否应该只展开它?
.NET takes the approach you'd like: you can't tell it to only use a certain amount of heap. Sometimes it feels like that's a better idea, but other times it's nice to be able to have two processes on the same machine and know that neither of them will be able to hog the whole of the memory...
.NET采用你想要的方法:你不能告诉它只使用一定数量的堆。有时感觉这是一个更好的主意,但有时候能够在同一台机器上拥有两个进程并且知道它们都不能占用整个内存是很好的...
#2
I glanced by this the other day, but I'm not sure if this is what you want: -XX:+AggressiveHeap. According to Sun:
前几天我瞥了一眼,但我不确定这是不是你想要的:-XX:+ AggressiveHeap。根据Sun的说法:
This option instructs the JVM to push memory use to the limit: the overall heap is more than 3850MB, the allocation area of each thread is 256K, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1_02) some GC activity is done in parallel.
此选项指示JVM将内存使用限制在极限:整个堆大于3850MB,每个线程的分配区域为256K,内存管理策略尽可能延迟收集,并且(从J2SE 1.3.1_02开始)一些GC活动是并行完成的。
Because this option sets heap size, do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size.
由于此选项设置堆大小,因此请勿将-Xms或-Xmx选项与-XX:+ AggressiveHeap结合使用。这样做会导致选项覆盖彼此的堆大小设置。
I wasn't sure if this really meant what I thought it meant, though - that you could just let the JVM gobble up heap space until it is satisfied. However, it doesn't sound like it's a good option to use for most situations.
我不确定这是否真的意味着我认为它意味着什么 - 你可以让JVM吞噬堆空间直到它满意为止。但是,在大多数情况下,它听起来不是一个很好的选择。
#3
I would think that it's good to be able to provide a limit so that if you have a memory issue it doesn't gobble up all the system memory leaving you with only a reboot option.
我认为能够提供一个限制是好的,这样如果你有一个内存问题它不会吞噬所有的系统内存,只留下你的重启选项。
#4
Java is a cross-platform system. Some systems (like Unix and derviates) have a ulimit command which allows you to limit how much memory a process can use. Others don't. Plus Java is sometimes run embedded, for example in a web browser. You don't want a broken applet to bring down your desktop (well, that was at least the idea but applets never really caught on but that's another story). Essentially, this option is one of the key cornerstones for sandboxing.
Java是一个跨平台系统。某些系统(如Unix和derviates)具有ulimit命令,允许您限制进程可以使用的内存量。其他人没有。加上Java有时是嵌入式的,例如在Web浏览器中。你不希望一个破碎的applet关闭你的桌面(好吧,至少这个想法,但applets从未真正流行,但这是另一个故事)。从本质上讲,此选项是沙盒的关键基石之一。
So the VM developers needed a portable solution: They added an option to the VM which would allow anyone (user, admin, web browser) to control how much RAM a VM could allocate tops. The needs of the various uses of Java are just too diverse to have one size fits all.
因此,VM开发人员需要一个可移植的解决方案:他们为VM添加了一个选项,允许任何人(用户,管理员,Web浏览器)控制VM可以分配多少RAM。 Java的各种用途的需求太多了,不适合所有人。
This becomes even more important today when you look at mobile devices. You desktop has 2-8GB RAM but your mobile has probably much less. And for these things, you really don't want one bad app to bring down the device because there might not even be a user who could check.
当你看到移动设备时,这变得更加重要。您的桌面有2-8GB内存,但您的手机可能要少得多。对于这些事情,你真的不希望一个坏的应用程序关闭设备,因为甚至可能没有用户可以检查。
#1
Even now, the heap doesn't grow without limit.
即使是现在,堆也不会无限制地增长。
When the oldest generation is full, should you expand it or just GC? Or should you only expand it if a GC doesn't free any memory?
当最老一代已满时,您应该扩展它还是仅仅GC?或者,如果GC没有释放任何内存,您是否应该只展开它?
.NET takes the approach you'd like: you can't tell it to only use a certain amount of heap. Sometimes it feels like that's a better idea, but other times it's nice to be able to have two processes on the same machine and know that neither of them will be able to hog the whole of the memory...
.NET采用你想要的方法:你不能告诉它只使用一定数量的堆。有时感觉这是一个更好的主意,但有时候能够在同一台机器上拥有两个进程并且知道它们都不能占用整个内存是很好的...
#2
I glanced by this the other day, but I'm not sure if this is what you want: -XX:+AggressiveHeap. According to Sun:
前几天我瞥了一眼,但我不确定这是不是你想要的:-XX:+ AggressiveHeap。根据Sun的说法:
This option instructs the JVM to push memory use to the limit: the overall heap is more than 3850MB, the allocation area of each thread is 256K, the memory management policy defers collection as long as possible, and (beginning with J2SE 1.3.1_02) some GC activity is done in parallel.
此选项指示JVM将内存使用限制在极限:整个堆大于3850MB,每个线程的分配区域为256K,内存管理策略尽可能延迟收集,并且(从J2SE 1.3.1_02开始)一些GC活动是并行完成的。
Because this option sets heap size, do not use the -Xms or -Xmx options in conjunction with -XX:+AggressiveHeap. Doing so will cause the options to override each other's settings for heap size.
由于此选项设置堆大小,因此请勿将-Xms或-Xmx选项与-XX:+ AggressiveHeap结合使用。这样做会导致选项覆盖彼此的堆大小设置。
I wasn't sure if this really meant what I thought it meant, though - that you could just let the JVM gobble up heap space until it is satisfied. However, it doesn't sound like it's a good option to use for most situations.
我不确定这是否真的意味着我认为它意味着什么 - 你可以让JVM吞噬堆空间直到它满意为止。但是,在大多数情况下,它听起来不是一个很好的选择。
#3
I would think that it's good to be able to provide a limit so that if you have a memory issue it doesn't gobble up all the system memory leaving you with only a reboot option.
我认为能够提供一个限制是好的,这样如果你有一个内存问题它不会吞噬所有的系统内存,只留下你的重启选项。
#4
Java is a cross-platform system. Some systems (like Unix and derviates) have a ulimit command which allows you to limit how much memory a process can use. Others don't. Plus Java is sometimes run embedded, for example in a web browser. You don't want a broken applet to bring down your desktop (well, that was at least the idea but applets never really caught on but that's another story). Essentially, this option is one of the key cornerstones for sandboxing.
Java是一个跨平台系统。某些系统(如Unix和derviates)具有ulimit命令,允许您限制进程可以使用的内存量。其他人没有。加上Java有时是嵌入式的,例如在Web浏览器中。你不希望一个破碎的applet关闭你的桌面(好吧,至少这个想法,但applets从未真正流行,但这是另一个故事)。从本质上讲,此选项是沙盒的关键基石之一。
So the VM developers needed a portable solution: They added an option to the VM which would allow anyone (user, admin, web browser) to control how much RAM a VM could allocate tops. The needs of the various uses of Java are just too diverse to have one size fits all.
因此,VM开发人员需要一个可移植的解决方案:他们为VM添加了一个选项,允许任何人(用户,管理员,Web浏览器)控制VM可以分配多少RAM。 Java的各种用途的需求太多了,不适合所有人。
This becomes even more important today when you look at mobile devices. You desktop has 2-8GB RAM but your mobile has probably much less. And for these things, you really don't want one bad app to bring down the device because there might not even be a user who could check.
当你看到移动设备时,这变得更加重要。您的桌面有2-8GB内存,但您的手机可能要少得多。对于这些事情,你真的不希望一个坏的应用程序关闭设备,因为甚至可能没有用户可以检查。