【Java引用规范】弱引用

已于 2024-03-02 15:01:50 修改
阅读量552 收藏 10
点赞数 8
分类专栏： Java引用关系 文章标签： java 开发语言
于 2024-01-22 10:18:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/azir_/article/details/135741701
版权

在上一期，对于强软引用我们已经有了一个认知了，这期介绍一下弱引用。

弱引用（Weak Reference）

概念和特性

我们在研究一个类的用处时，可以先看一下这个类上的注释，JDK上的注释对于该类的说明以及作用都会有着详细说明。

Weak reference objects, which do not prevent their referents from being made finalizable, finalized, and then reclaimed.

弱引用对象，这不会阻止它们的引用成为可终结的、结束的，之后被回收。
说人话就是弱引用与引用对象之间的关系相当于没有，不会让引用对象无法被垃圾处理器回收，只是一个定义而已。
弱引用其实在我们日常开发中也经常用到，那就是隐藏在ThreadLocal类中的Entry类。Entry继承了弱引用，并存放了在线程上下文都能访问的对象，以便在线程内共享变量。

static class Entry extends WeakReference<ThreadLocal<?>> {
    /** The value associated with this ThreadLocal. */
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

插播一下广告，在使用ThreadLocal会有内存泄漏的风险，这一点在我的专栏《ThreadLocal详解》中会说到，大家可以去看一下😀。

创建和使用示例

Object object = new Object();
WeakReference<Object> weakReference = new WeakReference<>(object);

使用上面的代码就能创建一个弱引用的对象了。

弱引用对垃圾回收的影响

跟上期一样，从结果看本质，我们还是根据程序在内存中的变化来梳理出，弱引用在垃圾回收时，JVM到底做了啥，从而看出弱引用对垃圾回收的影响。

示例代码

使用程序代码与上期介绍软引用的类似，不过在每次循环中增加了转储内存快照的功能。

package com.zsk;

import com.sun.management.HotSpotDiagnosticMXBean;

import javax.management.MBeanServer;
import java.io.IOException;
import java.lang.management.ManagementFactory;
import java.lang.ref.WeakReference;
import java.text.SimpleDateFormat;
import java.util.ArrayList;
import java.util.Date;
import java.util.List;

public class Main {
    public static void main(String[] args) throws InterruptedException, IOException {
        weakReference();
    }

    private static void weakReference() throws InterruptedException, IOException {
        List<WeakReference<int[]>> arrayList = new ArrayList<>();
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyyMMddHHmmss");
        while (true) {
            Thread.sleep(1000L);
            WeakReference<int[]> weakReference = new WeakReference<>(new int[(int) 1e7]);
            arrayList.add(weakReference);
            Date date = new Date();
            String format = simpleDateFormat.format(date);
            System.out.println(format);
            dumpHeap(format);
        }
    }

    private static void dumpHeap(String time) throws IOException {
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
        String diagnosticName = "com.sun.management:type=HotSpotDiagnostic";

        HotSpotDiagnosticMXBean diagnosticMXBean = ManagementFactory.newPlatformMXBeanProxy(
                mbs, diagnosticName, HotSpotDiagnosticMXBean.class);
        String dumpFilePath = "D:\\file\\Azir\\hprof\\" + time + ".hprof";
        try {
            // 生成堆转储
            diagnosticMXBean.dumpHeap(dumpFilePath, false);
            System.out.println("Heap dump created at: " + dumpFilePath);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

启动JVM参数：
-Xms512m -Xmx512m -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps
-Xloggc:D:\file\Azir\1.log

运行产出

在程序运行一段时间后，我们能得到3个东西

  1. 堆内存的运行变化图

我们通过IDEA的profiler功能（该功能的开启可以看看我上一期写的文章），就能看到下面这个有规律的内存运行变化图了。
20240118151936_rec_.gif

  1. GC的log日志

image.png

  1. 每秒钟转储的内存快照

image.png
根据这3个东西，我们就能分析出在垃圾回收时是怎么特殊处理弱引用的。

GC日志学习

在分析之前，先学习一下并行垃圾回收器垃圾回收前后的日志。在程序运行一段时间后，我们可以从log文件中得到类似下面的日志文件，随机提取一段来解析一下。
image.png
蓝框1：GC前堆内存的使用情况

  • 绿框3：年轻代的使用情况
日志块含义
PSYoungGen年轻代GC情况
total 171008K总共171008K≈167M
used 133536K已使用159938K≈156.1M
0x00000000f5580000使用的内存开始地址
0x0000000100000000目前使用到的地址
0x0000000100000000使用的内存结束地址
eden spaceeden区

- 167424K
总共167424K≈163.5M

- 95% used
已使用95%的内存空间

根据上面的日志，我们可以计算出整个年轻代一共申请的空间为：
0x0000000100000000-0x00000000f5580000≈174592K≈170.5M
计算得出的空间（170.5M）与显示的（167M）不一致，这个问题大家可以想想为什么，留个课外作业。
eden区 总共167424K≈163.5M 95%使用率≈155.325M

  • 绿框4：老年代的使用情况
  • 绿框5：元空间的使用情况（元空间所使用的内存空间并不占用堆内存的空间）

蓝框2：GC后堆内存的使用情况

蓝框1和绿框1中间夹着的就是本次垃圾回收的简略信息了

2024-01-18T16:08:25.999+0800: 77.382: [GC (Allocation Failure) [PSYoungGen: 159938K->192K(171008K)] 396850K->276254K(520704K), 0.0155949 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
日志块含义
2024-01-18T16:08:25.999+0800程序运行的当前时间
77.382启动到本次GC，程序总共运行时间
Allocation Failure空间分配失败，常见于对象创建
PSYoungGen年轻代的GC
159938K之前使用的内存大小
192K垃圾回收后的内存大小
171008K总内存大小
396850K垃圾回收前堆内存的大小
276254K垃圾回收后堆内存的大小
520704K堆内存大小
0.0155949 secs本次垃圾回收的持续时间
user=0.01用户CPU时间
sys=0.00系统CPU时间
real=0.01CPU总共使用的时间，专业一点叫墙钟时间（wall clock time）

GC做了啥

对于弱引用来说，GC究竟做了啥呢，我们可以抽取两段比较有意思的内存变化趋势来分析一下。
image.png
分别为25-26秒以及35-36秒，这两个区间的内存快照

25-26秒

这个时间段内存变化量不大，但是也有一定的降低量。肯定是进行了一次GC，至于是什么类型的GC。我们则需要到GC日志中看一下。

{Heap before GC invocations=17 (full 0):
 PSYoungGen      total 171008K, used 159938K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 167424K, 95% used [0x00000000f5580000,0x00000000ff198b80,0x00000000ff900000)
  from space 3584K, 2% used [0x00000000ffc80000,0x00000000ffc98000,0x0000000100000000)
  to   space 3584K, 0% used [0x00000000ff900000,0x00000000ff900000,0x00000000ffc80000)
 ParOldGen       total 349696K, used 236912K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 67% used [0x00000000e0000000,0x00000000ee75c078,0x00000000f5580000)
 Metaspace       used 9512K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
2024-01-18T16:08:25.999+0800: 77.382: [GC (Allocation Failure) [PSYoungGen: 159938K->192K(171008K)] 396850K->276254K(520704K), 0.0155949 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
Heap after GC invocations=17 (full 0):
 PSYoungGen      total 171008K, used 192K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 167424K, 0% used [0x00000000f5580000,0x00000000f5580000,0x00000000ff900000)
  from space 3584K, 5% used [0x00000000ff900000,0x00000000ff930000,0x00000000ffc80000)
  to   space 3072K, 0% used [0x00000000ffd00000,0x00000000ffd00000,0x0000000100000000)
 ParOldGen       total 349696K, used 276062K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 78% used [0x00000000e0000000,0x00000000f0d97a88,0x00000000f5580000)
 Metaspace       used 9512K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
}

上面这段内存就是25-26秒中，GC回收的日志了。经过上一节对于GC日志的学习，我们可以很简单的看出，是由于年轻代内存分配失败，导致进行了一次GC。
我们对这段GC日志再分析一下，一共有几个点在GC前后是有变化的。

  1. eden区的占用变化了，从95%降低到了0%，回收了159052K≈155.3M。

由于我们程序只有一个功能，那就是创建一个内存占用为38M的大数组，并放在ArrayList中。此时，eden区被回收的内存155M刚好是38M的四倍，并且本次GC是因为内存空间分配失败导致的，所以我们可以得出第一个结论：

在eden区创建第五个大数组时，由于内存不足，进行了一次年轻代的GC。

  1. from区的占用变化了，从2%升高到了5%，增加了107.5K≈0.1M。

内存变化太少，分析不出什么结论。

  1. 老年代的占用变化了，从67%升高到了78%，增加了38466K≈37.5M。

这个37.5M与我们大数组的空间38M相差无几，由于GC日志显示的百分比是有误差的，所以我们再去看看老年代真正增加了多少内存空间的使用。
GC前：total 349696K, used 236912K
GC后：total 349696K, used 276062K
GC后增加了39150K≈38.2M，这个数值与大数组的内存相同。此时，我们又可以得出第二个结论：

在进行年轻代的GC前后，有一个大数组晋级到了老年代中。

根据日志分析得出的两个结论再去内存快照中验证一下，看是否与我们分析的一致。

将25秒和26秒的内存快照导入到MAT工具中分析后，对比一下GC前后，有哪几个大数组被清理了，有哪个大数组晋级到了老年代了。
image.png

左边为GC前，右边为GC后

我们可以看到，GC后58、59、60号的大数组对象被回收了，那么被晋级到老年代的大数组肯定就是57号大数组了。这个结论我们可以根据GC前后57号大数组的内存地址对比一下。
image.png
GC前0xf5580000位于年轻代中[0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
GC后0xee772078位于老年代中[0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
所以上面得出的两个结论是正确的：

  1. 在eden区创建第五个大数组时，由于内存不足，进行了一次年轻代的GC。
  2. 在进行年轻代的GC前后，有一个大数组晋级到了老年代中。

根据这两个结论，我们可以归纳总结一下，那就是：

在年轻代内存空间不足时，会将弱引用引用的对象进行清理

对象的晋级是一个通用的规则，而不是弱引用导致的。

35-36秒

这个时间段中，内存的变化量极大。一眼就能看出，肯定进行了一次Full GC了，这个我们去看一下GC日志也能得出。

{Heap before GC invocations=18 (full 0):
 PSYoungGen      total 171008K, used 160025K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 167424K, 95% used [0x00000000f5580000,0x00000000ff196768,0x00000000ff900000)
  from space 3584K, 5% used [0x00000000ff900000,0x00000000ff930000,0x00000000ffc80000)
  to   space 3072K, 0% used [0x00000000ffd00000,0x00000000ffd00000,0x0000000100000000)
 ParOldGen       total 349696K, used 276062K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 78% used [0x00000000e0000000,0x00000000f0d97a88,0x00000000f5580000)
 Metaspace       used 9525K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
2024-01-18T16:08:34.178+0800: 85.561: [GC (Allocation Failure) [PSYoungGen: 160025K->128K(171520K)] 436088K->315285K(521216K), 0.0157927 secs] [Times: user=0.19 sys=0.02, real=0.02 secs] 
Heap after GC invocations=18 (full 0):
 PSYoungGen      total 171520K, used 128K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 168448K, 0% used [0x00000000f5580000,0x00000000f5580000,0x00000000ffa00000)
  from space 3072K, 4% used [0x00000000ffd00000,0x00000000ffd20000,0x0000000100000000)
  to   space 3072K, 0% used [0x00000000ffa00000,0x00000000ffa00000,0x00000000ffd00000)
 ParOldGen       total 349696K, used 315157K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 90% used [0x00000000e0000000,0x00000000f33c5498,0x00000000f5580000)
 Metaspace       used 9525K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
}

{Heap before GC invocations=19 (full 1):
 PSYoungGen      total 171520K, used 128K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 168448K, 0% used [0x00000000f5580000,0x00000000f5580000,0x00000000ffa00000)
  from space 3072K, 4% used [0x00000000ffd00000,0x00000000ffd20000,0x0000000100000000)
  to   space 3072K, 0% used [0x00000000ffa00000,0x00000000ffa00000,0x00000000ffd00000)
 ParOldGen       total 349696K, used 315157K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 90% used [0x00000000e0000000,0x00000000f33c5498,0x00000000f5580000)
 Metaspace       used 9525K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
2024-01-18T16:08:34.194+0800: 85.577: [Full GC (Ergonomics) [PSYoungGen: 128K->0K(171520K)] [ParOldGen: 315157K->2574K(349696K)] 315285K->2574K(521216K), [Metaspace: 9525K->9525K(1058816K)], 0.0077757 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
Heap after GC invocations=19 (full 1):
 PSYoungGen      total 171520K, used 0K [0x00000000f5580000, 0x0000000100000000, 0x0000000100000000)
  eden space 168448K, 0% used [0x00000000f5580000,0x00000000f5580000,0x00000000ffa00000)
  from space 3072K, 0% used [0x00000000ffd00000,0x00000000ffd00000,0x0000000100000000)
  to   space 3072K, 0% used [0x00000000ffa00000,0x00000000ffa00000,0x00000000ffd00000)
 ParOldGen       total 349696K, used 2574K [0x00000000e0000000, 0x00000000f5580000, 0x00000000f5580000)
  object space 349696K, 0% used [0x00000000e0000000,0x00000000e0283be0,0x00000000f5580000)
 Metaspace       used 9525K, capacity 9832K, committed 9984K, reserved 1058816K
  class space    used 1077K, capacity 1165K, committed 1280K, reserved 1048576K
}

从日志文件中可以看出，一共进行了两次GC。分别为：

  1. 年轻代内存分配失败导致的GC
  2. 由于Ergonomics导致的Full GC

第一次GC的原因与25-26秒的原因一致，就不再重复了。在这一节，主要分析一下Full GC的原因。
什么是Ergonomics呢？
image.png
百度翻译为人体工学，对于我们分析来说毫无意义。这里我先提一嘴吧，这个单词在HotSpot虚拟机的C++代码中可以找到，位于gcCause.cpp文件中，含义为adaptive_size_policy，就是自适应大小策略的意思。
image.png

有关HotSpot虚拟机对于引用是怎么进行垃圾回收的，在后面我也会讲到，大家敬请期待。

话说回来，因为自适应大小策略的原因，导致了一次Full GC，那么针对内存大小，GC前后有哪些变化呢？

  1. 年轻代空间被完全回收，128K降低至0K。

内存变化太少，分析不出什么结论。

  1. 老年代空间被完全回收，315157K降低至2574K，减少了312583K≈305M。

老年代的内存被全部回收了，回收的内存空间也正好是8个大数组的空间，所以也能得出一个结论，弱引用也有软引用的一个特性：在OOM抛出之前，会将引用的对象全部清空。
用内存快照来验证一下上面得出的结论：
image.png

左边为GC前，右边为GC后

可以看到GC后，ArrayList中存放的弱引用所引用的大数组都被回收完了。

结论

弱引用不但有着软引用的特性之外，还存在着哪个内存分层空间中达到上限后，都会将弱引用给清空。
所以在动图的每一次内存使用空间的降低时，都触发了一次垃圾回收。

下期预告：虚引用以及神秘的引用队列

Azir_12138
关注
  • 8
    点赞
  • 踩
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Java中的引用：强软弱虚
lypeer的专栏
04-25 5423
前言 之前在研究MVP的时候接触过弱引用，用来避免由于Activity被回收导致的内存泄露，但是当时只是浅尝辄止，没有系统的去接触引用这一块，没想到最近在看ThreadLocal的时候又看到关于引用的东西了，于是干脆就把这一块的东西都整理一下。正文1，引用是什么每种语言都有自己的数据处理方式，比如在c或c++中我们经常使用指针来间接的操纵对象，而在Java中，操纵的标识符实际上是指向一个对象的“句柄”
Java通过What、Why、How了解弱引用
08-19
在Java编程语言中，弱引用是一种特殊的引用类型，它允许开发者在特定场景下更精细地控制对象的生命周期。本文将从What、Why、How三个方面详细解释弱引用的概念、使用原因及其实现方式。 What——什么是弱引用？ 弱...
Java中强、软、弱、虚、终结引用实例详解
全栈行动派的博客
03-13 1861
Java中强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）详解、使用场景、创建方法、回收实例代码详解
JAVA基础 - 强引用、弱引用、软引用、虚引用
热门推荐
zs1972551648的博客
02-28 1万+
强引用：不会被回收； 软应用：内存不足时回收 弱引用：正常垃圾回收 虚引用：跟踪对象的正常垃圾回收 ...
Java 中什么是弱引用
m0_60521228的博客
02-16 809
弱引用（Weak Reference）是一种特殊的引用关系，在计算机程序设计中，与强引用相对。弱引用的主要特点是它不能确保其引用的对象不会被垃圾回收器回收。如果一个对象只被弱引用所引用，那么该对象会被认为是不可访问（或弱可访问）的，因此它可能在任何时刻被垃圾回收器回收。弱引用的存在不会影响对象的回收。只要垃圾回收机制运行，无论内存空间是否足够，都会回收被弱引用关联的对象。这种机制允许对象在适当的时机被垃圾回收，从而避免内存泄漏。当内存不足时，JVM（Java虚拟机）会优先回收被弱引用关联的对象。
一文讲透java弱引用以及使用场景
lucasma的博客
05-05 5024
这个线程的逻辑就是：不断的从Reference构成的pending链表上获取Reference对象，如果pending不为null，则将pending的对象进行clean，如果注册的时候有queue就进行enqueue，否则线程进行wait状态。
java编码规范.zip
12-26
本压缩包“java编码规范.zip”提供了华为版的编码规范和一个详细的Java代码规范版本，旨在帮助开发者遵循一致的规则，编写出易于阅读、维护的高质量代码。 首先，我们来看华为版的Java编码规范。华为作为全球知名的...
阿里java开发规范2022最新版
05-11
- **内存管理**：合理使用对象，避免内存泄漏，理解并适时使用软引用、弱引用。 - **循环优化**：减少循环内的计算，避免在循环中创建不必要的对象，使用 for-each 循环简化代码。 - **IO优化**：使用缓冲读写，...
Java虚拟机规范中文版（JavaSE7）.pdf
09-23
Java虚拟机规范（Java SE 7版）是定义JVM行为的官方文档，确保所有Java平台的实现遵循相同的规则，以提供跨平台的兼容性和一致性。这份规范涵盖了虚拟机的结构、字节码编译、字节码文件格式、类加载机制以及虚拟机...
JAVA源代码规范.doc
11-24
JAVA 源代码规范 Java 源代码规范是一个重要的软件工程文档，旨在提供一整套编写高效可靠的 Java 代码的标准、约定和指南。该规范旨在提高 Java 软件开发者的生产效率，并为开发团队的程序设计带来更大的一致性。 ...
Java弱引用（WeakReference）的一点认识
Xmos的博客
02-16 823
Java弱引用（WeakReference）的一点认识 首先我们看下虚引用的定义 "虚引用"顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。 这个仅字很关键，说明虚引用的目的是为了当对象引用为null时，能及时的被垃圾回收器回收。代码示例如下： String value = new String("abc"); WeakReference<String> abc = new WeakR
Java基础-强引用、弱引用、软引用、虚引用
m0_56663972的博客
06-14 770
在Java 程序中，最常见的引用类型是强引用，它也是默认的引用类型。软引用是除了强引用外最强的引用类型，我们可以通过java.lang.ref.SoftReference使用软引用。垃圾回收器某个时刻决定回收软可达的对象的时候，会清理软引用，并可选的把引用存放到一个引用队列（ReferenceQueue）。当在Java语言中使用new 操作符创建一个新的对象，并将其赋值给一个变量的时候，这个变量就成为指向该对象的一个强引用。其次虚引用对象的get方法总是返回null，因此无法通过虚引用来获取被引用的对象。
Java：强引用，软引用，弱引用和虚引用
qq_43842093的博客
06-24 815
引用类型被回收时间用途生存时间强引用从来不会对象的一般状态JVM停止运行时软引用内存不足时对象缓存内存不足时弱引用jvm垃圾回收时对象缓存gc运行后虚引用未知未知未知在实际程序设计中一般很少使用弱引用与虚引用，使用软引用的情况较多，这是因为软引用可以加速JVM对垃圾内存的回收速度，可以维护系统的运行安全，防止内存溢出（OutOfMemory）等问题的产生。
理解Java中的强引用，软引用，弱引用，虚引用
Coder编程的博客
10-30 465
原文地址：https://blog.csdn.net/qq_39192827/article/details/85611873 前言 在JDK1.2以前的版本中，当一个对象不被任何变量引用，那么程序就无法再使用这个对象。也就是说，只有对象处于可触及状态，程序才能使用它。这就像在商店购买了某样物品后，如果有用就一直保留它，否则就把它扔到垃圾箱，由清洁工人收走。一般说来，如果物品已经被扔到垃圾箱，想再...
（转）Java中的四种引用
weixin_30752377的博客
10-27 475
强引用(Strong Reference) 强引用就是我们经常使用的引用，其写法如下 1 StringBuffer buffer = new StringBuffer(); 上面创建了一个StringBuffer对象，并将这个对象的（强）引用存到变量buffer中。是的，就是这个小儿科的操作（请原谅我这样的说法）。强引用最重...
Java引用（强引用和弱引用）
看见什么心乱
07-08 2540
众所周知，Java中是由JVM负责内存的分配和回收，它的优点是使用方便，程序员不用再像使用c那样操心内存，但同时也是它的缺点，不够灵活。为了解决内存操作不灵活这个问题，可以采用弱引用等方法。在JDK1.2以前的版本中，当一个对象不被任何变量引用，那么程序就无法再使用这个对象。也就是说，只有对象处于可触及状态，程序才能使用它。这就像在日常生活中，从商店购买了某样物品后，如果有用，就一直保留它，否则就把它扔到垃圾箱，由清洁工人收走。但有时候情况并不这么简单，你可能会遇到类似以鸡肋一样的物品，食之无味，弃之可惜。
Java弱引用(WeakReference)的理解与使用
u010227042的博客
09-13 1705
而复杂一点的情况，比如使用cache,因为cache的对象正是程序运行需要的, 那么只要程序正在运行, cache中的引用就不会被GC，那么随着cache中的引用越来越多, GC无法回收的对象也越来越多, 无法被自动回收，此时就必须有开发者来进行处理回收，显然也违背了java自动回收机制。Java对于简单的情况, 手动置空是不需要程序员来做的, 因为在java中, 对于简单对象, 当调用它的方法执行完毕后, 指向它的引用会被GC回收，Person p = new Person("张三",18,"男");
强引用和弱引用
java_x_b的博客
07-11 808
需要注意的是，使用弱引用时需要小心处理，因为弱引用的对象随时可能被垃圾回收器回收。在使用弱引用时，推荐在访问弱引用获取对象时进行必要的空值检查，以确保对象尚未被回收。在Java中，引用可以分为不同的类型，其中包括强引用（Strong Reference）和弱引用（Weak Reference）。是一个弱引用，它引用了。在Java中，可以通过。可以被垃圾回收器回收。不再有强引用指向时，
12. Hibernate 模板设计模式
最新发布
这是一个web全栈开发的博客，取其精华去其糟粕，争取让大家一看就懂，一学就会，一用就成~
07-22 1248
如何运用模板设计模式重构 Hibernate 操作流程；持久化对象与序列化接口；OOP中有一个编码原则 ：写仅写一次。翻译过来就是，不要重复，要重用。答案是：使用模板设计模式进一步封装Hibernate的操作。在真实项目中，Hibernate仅仅只是完成项目中的一部分工作，需要和其它，如Spring等框架联合工作，一起承担整体项目的开发。Spring框架中就提供的有Hibernate模板对象。一个常规的、频繁的操作代码中，大部分代码不需要变动，只有小部分代码需要根据需求变动。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值