java堆的大小
㈠ java的堆内存是什么
Java堆（Java Heap）是java虚拟机所管理的内存中最大的一块
java堆被所有线程共享的一块内存区域
虚拟机启动时创建java堆
java堆的唯一目的就是存放对象实例。
java堆是垃圾收集器管理的主要区域。
从内存回收的角度来看， 由于现在收集器基本都采用分代收集算法， 所以Java堆可以细分为：新生代（Young）和老年代（Old）。 新生代又被划分为三个区域Eden、From Survivor， To Survivor等。无论怎么划分，最终存储的都是实例对象， 进一步划分的目的是为了更好的回收内存， 或者更快的分配内存。
java堆的大小是可扩展的， 通过-Xmx和-Xms控制。
如果堆内存不够分配实例对象， 并且对也无法在扩展时， 将会抛出outOfMemoryError异常。
㈡ 查看java对象占堆内存多少个字节
object
o=new
object():
在java中空对象占八个字节，对象的引用占四个字节。所以上面那条语句所占的空间是4byte+8byte=12byte.java中的内存是以8的倍数来分配的，所以分配的内存是16byte.
举个例子：
class
o{
int
i;
byte
j;
string
s;
}
其所占内存的大小是空对象（8）+int(4)+byte(1)+string引用(4)=17byte,因要是8的整数倍，所以其占大小为24byte.
当然，如果类里有其他对象的话，也要把其他对象的空间算进去。
㈢ java 虚拟机堆的大小怎样查看
命令行
java –Xms128m //JVM占用最小内存
–Xmx512m //JVM占用最大内存
–XX:PermSize=64m //最小堆大小
–XX:MaxPermSize=128m //最大堆大小
㈣ java中有最大堆吗
虚拟机上有你说这参数，正常情况不用调整，虚拟机会自行管理。尤其jdk8的虚拟机有几个跟内存相关的参数，调整了也不生效。java里面没听说过需要自行控制堆大小，也没听说过可以自行改变堆大小的api。控制堆的职责在虚拟机实现，对虚拟机启动参数理解够好可以自行调整。
补充一点其他知识：堆，栈的控制，操作系统api会提供此功能。直接运行在操作系统上的进程，可以调用到系统api。如虚拟机一般就是c+系统api实现的。因此虚拟机自身可以堆栈cpu等等系统资源。而操作系统可看成与硬件直接打交道的接口平台（实际上又封装了N层，不用管）。能了解此段的内容，理解第一段应该没问题了。java可以直接访问操作系统库，很少有应用这么用。或者就不推荐这么用，如果这么用为什么不直接用系统api？此处别钻牛角尖。java有安全机制，如果访问操作系统底层的api能否可行不清楚。我也没试过。
㈤ java设置堆初始值大小为1G的命令参数为
一般系统会默认给定物理内存的四分之一作为你java运行的最大内存, 这个说法是错误的,中间件的内存分配都是根据中间间的设置来指定的,如不设置默认为0,而不是自动默认1/4。
㈥ jvm默认多大的对象是大对象
jvm默认多大的对象是大对象？对象的内存分配——对象优先在Eden分配
当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
testAllocation()方法中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过-Xms20M、-Xmx20M、-Xmn10M这3个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8:1，从输出的结果也可以清晰地看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变为162KB，而总内存占用量则几乎没有减少（因为allocation1、allocation2、allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只好通过分配担保机制提前转移到老年代去。这次GC结束后，4MB的allocation4对象顺利分配在Eden中，因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、allocation2、allocation3占用）。
下面看看使用Parallel Scavenge收集器的情况：
没有发生新生代GC，直接把allocation4分配到老年代上。
对象的内存分配——大对象直接进入老年代——典型的大对象
很长的字符串以及数组
对象的内存分配——大对象直接进入老年代——大对象噩梦
比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。
对象的内存分配——大对象直接进入老年代——原因
大于-XX:PretenureSizeThreshold设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。
PretenureSizeThreshold被设置为3MB（就是3145728，这个参数不能像-Xmx之类的参数一样直接写3MB），因此超过3MB的对象都会直接在老年代进行分配。
PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。
㈦ JAVA虚拟机的最大堆大小如何设置
虚拟机的堆大小设置不属于java标准选项，也就是说实现一个java虚拟机，不一定要支持这个功能。
不过流行的发行版都是实现了这个选项，输入java -X，会输出有哪些非标准选项被支持。
单独输入这个选项（-Xms），是不能工作的，缺少必要的class参数，请注意提示的用法那一段中，非中括号的部分，那些是必选的。
正确用法:
java -Xss64m Test
Test是class的名字
㈧ java堆内存大小是多少，取决于什么
这个看下jdk帮助文档就行
返回的是字节，所以是247.5MB
㈨ JAVA虚拟机的堆大小如何设置
java –Xms128m //JVM占用最小内存
–Xmx512m //JVM占用最大内存
–XPermSize=64m //最小堆大小
–XMaxPermSize=128m //最大堆大小
㈩ java堆的大小包括加上方法区（持久代）的大小吗
首先你说的“持久代”仅仅是HotSpot存在的一个概念，并且将其置于方法区，JRocket与IBM的VM都不存在这个“持久代”，最新的HotSpot也计划将其移除。所以你说的都对，在heap中和在Method Area中并没定论。