JVM对象(更新)

对象创建方式

Header解释
使用new关键字调用了构造函数
使用Class的newInstance方法调用了构造函数
使用Constructor类的newInstance方法调用了构造函数
使用clone方法没有调用构造函数
使用反序列化没有调用构造函数

对象创建过程在这里插入图片描述

虚拟机遇到一条new指令时,先检查常量池是否已经加载相应的类,如果没有, 必须先执行相应的类加载。类加载通过后,接下来分配内存。若Java堆中内存是 绝对规整的,使用“指针碰撞“方式分配内存;如果不是规整的,就从空闲列表 中分配,叫做”空闲列表“方式。划分内存时还需要考虑一个问题-并发,也有 两种方式: CAS同步处理,或者本地线程分配缓冲(Thread Local Allocation Buffer, TLAB)。然后内存空间初始化操作,接着是做一些必要的对象设置(元信 息、哈希码…),后执行方法。


对象分配内存:

类加载完成后,接着会在Java堆中划分一块内存分配给对象。内存分配根据Java 堆是否规整,有两种方式:

  • 指针碰撞:如果Java堆的内存是规整,即所有用过的内存放在一边,而空闲的的放在另一边。分配内存时将位于中间的指针指示器向空闲的内存移动一段与对象大小 相等的距离,这样便完成分配内存工作。
  • 空闲列表:如果Java堆的内存不是规整的,则需要由虚拟机维护一个列表来记录 那些内存是可用的,这样在分配的时候可以从列表中查询到足够大的内存分配给对象,并在分配后更新列表记录。

选择哪种分配方式是由 Java 堆是否规整来决定的,而 Java 堆是否规整又由所 采用的垃圾收集器是否带有压缩整理功能决定。
在这里插入图片描述


对象定位

Java程序需要通过 JVM 栈上的引用访问堆中的具体对象。对象的访问方式取决 于 JVM 虚拟机的实现。目前主流的访问方式有 句柄直接指针 两种方式。

句柄访问

Java堆中划分出一块内存来作为句柄池,引用中存储对象的句柄地址,而句柄中 包含了对象实例数据对象类型数据各自的具体地址信息,具体构造如下图所 示:在这里插入图片描述
优势:引用中存储的是稳定的句柄地址,在对象被移动(垃圾收集时移动对象是 非常普遍的行为)时只会改变句柄中的实例数据指针,而引用本身不需要修改。

直接指针

如果使用直接指针访问,引用 中存储的直接就是对象地址,那么Java堆对象内 部的布局中就必须考虑如何放置访问类型数据的相关信息。在这里插入图片描述
优势:速度更快,节省了一次指针定位的时间开销。由于对象的访问在Java中非 常频繁,因此这类开销积少成多后也是非常可观的执行成本。HotSpot 中采用 的就是这种方式。

对象引用(与Threadlocal有关后续更新)

Java 中都有哪些引用类型?

  • 强引用:发生GC 的时候不会被回收。
  • 软引用:有用但不是必须的对象,在发生内存溢出之前会被回收。多用户缓存或者图片。
  • 弱引用:有用但不是必须的对象,在下一次GC时会被回收。
  • 虚引用(幽灵引用/幻影引用):无法通过虚引用获得对象,用PhantomReference 实现虚引用,虚引用的用途是在GC时返回一个通知。应用:管理堆外内存
<think> 嗯,用户想了解JVM对象的相关信息,包括定义、特点和处理机制。这个问题很有深度,需要结合JVM内存管理机制来解释。 用户之前没有问过相关问题,但根据系统要求,需要参考站内引用材料。引用[1][2][5]提到了对象创建和内存分配机制,引用[4]涉及垃圾回收,这些都是理解大对象的基础。 大对象JVM中是个重要概念。它的定义通常与具体垃圾收集器相关,比如G1收集器默认认为超过region大小50%的对象就是大对象。这类对象会直接进入老年代,避免在年轻代复制导致开销。 特点方面,大对象容易引发内存碎片,尤其是CMS收集器。而且分配时可能触发担保机制,甚至Full GC。处理机制上,JVM有TLAB和大对象特殊分配区,G1还有Humongous区专门管理。 用户可能是Java开发者,遇到了性能问题才关注这个点。需要提醒优化建议,比如避免频繁创建大对象、调整JVM参数等。最后按惯例生成相关问题,帮助用户深入理解。 </think> 以下是关于JVM对象的详细解析,结合引用材料和JVM机制: ### 一、大对象的定义 1. **标准定义** - 大对象指**超过特定阈值**的对象(具体阈值因收集器而异) - G1收集器中:**对象大小 > Region大小的50%**(默认Region=2MB,即对象>1MB) - CMS收集器:**通过`-XX:PretenureSizeThreshold`参数设定**(默认0,表示所有对象先在Eden分配) 2. **常见类型** - 大型数组(如`byte[1024*1024]`) - 长字符串(如JSON/XML解析的中间结果) - 集合类(HashMap/ArrayList存储海量数据) --- ### 二、核心特点 1. **分配机制特殊化** - 直接分配到**老年代**(跳过Eden区),避免年轻代复制开销[^2][^5] ```java // 示例:创建大对象(可能直接进入老年代) byte[] largeBuffer = new byte[2 * 1024 * 1024]; // 2MB对象 ``` 2. **内存碎片风险高** - 连续内存空间需求易导致**老年代碎片**(尤其CMS收集器)[^4] 3. **GC效率影响显著** - Full GC时移动大对象成本高(如Serial/CMS的标记-清除算法) - Young GC虽然不处理大对象,但碎片会间接拖慢GC速度 --- ### 三、JVM处理机制 1. **G1的Humongous区** - 专为>50% Region大小的对象设计 - 跨多个Region存放超大对象(通过`HumongousRegion`标记) - 回收策略:**优先在Mixed GC周期清理**(可通过`-XX:InitiatingHeapOccupancyPercent`调整触发阈值)[^4] 2. **分配优化策略** ```mermaid graph LR A[对象创建] --> B{对象大小 > 阈值?} B -->|是| C[直接分配至老年代] B -->|否| D[走常规TLAB分配流程] ``` 3. **垃圾回收影响** - 大对象会**加速老年代填充**,提高Full GC频率 - G1的Humongous区回收不及时会导致**并发模式失败**(Concurrent Mode Failure) --- ### 四、开发优化建议 1. **代码层面** - 避免频繁创建生命周期短的大对象(改用对象池) - 拆分大对象(如分块处理文件流) 2. **参数调优** ```bash # G1优化大对象处理 -XX:G1HeapRegionSize=4m # 增大Region尺寸 -XX:G1MixedGCLiveThresholdPercent=40 # 降低混合GC存活阈值 -XX:G1HeapWastePercent=10 # 允许更多堆空间浪费以避免Full GC ``` - CMS需显式设置阈值:`-XX:PretenureSizeThreshold=4194304`(4MB对象直接进老年代) --- ### 相关问题 1. G1的Humongous区回收是否会引发STW? 2. 如何诊断由大对象导致的内存碎片问题? 3. 对象池技术在大对象场景下的适用性与局限性? 4. ZGC/Shenandoah等新收集器对大对象的处理有何改进? > 参考文献 > [^1]: Java核心篇之JVM探秘:对象创建与内存分配机制 > [^2]: JVM对象内存管理机制 > [^4]: JVM垃圾回收机制与GC Roots > [^5]: JVM类加载与内存分配流程
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值