dw做网站一般需要多大尺寸宠物店做网站的论文

dw做网站一般需要多大尺寸,宠物店做网站的论文,建站公司合肥,建设网站的网站首页JDK每次大版本更新#xff0c;会有新的GC垃圾回收器ZGC、Shenandoah等#xff0c;然后我们就的没完没了的学#xff0c;死记硬背这些过几天很容易忘了。但如果弄明白GC垃圾回收器它们的本质在干什么#xff0c;就比较容易记忆了。认真搞清楚一个最基础、却最容易被忽略的问…JDK每次大版本更新会有新的GC垃圾回收器ZGC、Shenandoah等然后我们就的没完没了的学死记硬背这些过几天很容易忘了。但如果弄明白GC垃圾回收器它们的本质在干什么就比较容易记忆了。认真搞清楚一个最基础、却最容易被忽略的问题JVM里什么样的对象才配叫垃圾你可能会说这还不简单不用的对象就是垃圾呗。别急如果你真这么想那很可能你项目里的内存泄漏就是这么来的。咱们下边从表象到本质看看垃圾的定义、识别逻辑以及为什么 JVM 的设计如此精妙。不用 ≠ 垃圾先破个误区很多同学觉得这个对象我后面肯定不会用了JVM 应该把它回收掉。但现实是JVM根本不知道你用不用。它就是个死心眼的程序也不会分析你的业务逻辑它只认一个铁律只要程序还有可能访问到这个对象它就不是垃圾。哪怕你写完代码就忘了它只要还有一条引用链能触达它JVM 就会把它当活人供着一分内存都不能动。垃圾的判定标准不是主观无用是客观不可达。如何判断对象的可达JVM判断可达性靠的是一个叫做GC Roots的概念。我举个例子方便理解他想象一下你手里拿着一串葡萄。这串葡萄有主干主干上分出小枝小枝上挂着一颗颗葡萄粒。但有些葡萄粒已经掉了有的是连着一小段旁枝一起掉在桌上。现在你用手捏住葡萄串的主干这就是 GC Roots把整串提起来。所有还挂在串上、能被提起来的葡萄粒都是活着的对象而那些已经掉在桌面上、和主干彻底断开的无论它们看起来多完整都成了垃圾。JVM 的垃圾回收干的就是这件事它不关心葡萄好不好吃只关心你还能不能把它拎起来。什么能做 GC Roots能做 GC Roots 通常是我们平常接触过的一些变量和引用。当前正在执行的方法中的局部变量比如Object obj new Object();里的obj类的静态字段static 变量字符串常量池里的对象比如helloJNI本地方法中持有的 Java 对象引用被 synchronized 锁住的对象某些 JVM 实现注意new 对象本身不是 Root指向它的 obj 引用才是。举个例子public void demo() { Object a new Object(); // ← 这个 new Object() 能通过局部变量 a 访问 → 存活 } // 方法结束a 出栈 → 引用消失 → 对象不可达 → 成为垃圾看明白了吗对象的生死取决于有没有路能走到它。JVM怎么找路的那么问题来了JVM怎么知道哪些对象有路答案是遍历引用图做标记。整个过程分两步从所有 GC Roots 出发深度/广度遍历所有引用链给所有能访问到的对象打上“存活”标记。做完这两步剩下的对象没被打标的统统视为垃圾。你可以想象成JVM在内存里玩扫雷标出所有安全区剩下的全是雷垃圾等着清理。这个过程通常需要Stop-The-WorldSTW也就是暂停你的应用线程。为什么因为如果一边跑业务一边改引用遍历结果就不准了可能刚标完活下一秒就被置 null 了。特殊引用类型我们知道 Java 不只有强引用。它还提供了其他三种引用让开发者能更精细地控制对象生命周期。引用类型是否阻止回收典型用途强引用默认是普通对象只要存在就不会被回收软引用SoftReference内存不足时回收缓存系统如图片缓存弱引用WeakReference否下次 GC 就回收适合监听器、映射表虚引用PhantomReference否无法获取对象仅用于跟踪回收事件重点来了只有强引用才算真正的路径其他引用在 GC 眼里≈断头路。比如这也是为什么WeakHashMap能自动清理 key它的 key 是弱引用一旦外部不再强引用key 就清除了。WeakReferenceObject ref new WeakReference(new Object()); // 如果没有其他强引用这个对象在下一次 GC 时就会被回收垃圾 不可达对象到这我们可以给出精确的定义了JVM中垃圾是指从任意 GC Root 出发都无法通过引用链访问到的对象。注意这里有几个关键词任意 GC Root只要有一个 Root 能到达就不是垃圾引用链必须是强引用构成的路径当前时刻可达性是动态的对象可能“由活变死”。为什么理解这个很重要因为你写的每一行代码都在影响可达性很多写法正在阻止垃圾回收。这些是实际开发中不经意间影响可达性的常见写法。1.把对象塞进static集合却不清理users是 GC Root静态变量里面所有对象永远可达 →内存泄漏老年代缓慢增长直至 OOM。public class Cache { private static ListUser users new ArrayList(); public void addUser(User u) { users.add(u); // 加进去就不管了 } }2.监听器 / 回调未注销事件总线通常持有强引用即使页面/组件已关闭对象仍被持有 →Activity / Controller / Service 无法回收Android / Spring 常见坑。eventBus.register(this); // 注册监听器 // ... 但对象销毁时忘了 unregister3.内部类隐式持有外部类引用Runnable匿名内部类隐式持有Outer实例引用。如果该Runnable被长期持有如提交到线程池整个Outer对象含大数组都无法回收。可以改用static class或 lambda不捕获外部实例。public class Outer { private byte[] data new byte[1024 * 1024]; // 大对象 public Runnable getTask() { return new Runnable() { // 非静态内部类 public void run() { /* ... */ } }; } }4. ThreadLocal 使用后未 remove()ThreadLocal的值由线程的Thread对象间接持有Thread - ThreadLocalMap - Value。在线程池中线程复用 →Value 永远不释放→ 内存泄漏。可以在try-finally中调用remove()。private static ThreadLocalBigObject local new ThreadLocal(); public void process() { local.set(new BigObject()); // 忘记 local.remove(); }5. 大对象频繁创建又很快丢弃大对象直接进入老年代JVM 默认 一半 Eden 区的对象算大对象快速撑爆老年代 →触发 Full GC 甚至 OOM。for (int i 0; i 100000; i) { byte[] buffer new byte[1024 * 1024]; // 1MB 大数组 // 用完就丢 }6. 字符串拼接产生大量临时对象尤其在循环中产生大量短命StringBuilder和String对象加剧新生代 GC 压力。String s ; for (int i 0; i 10000; i) { s item i; // 每次都 new StringBuilder toString() }GC 它只是忠实地执行可达即活不可达即死的规则。而我们要做的就是确保真的不用的对象确实不可达。写在最后Java 的 GC 机制看似复杂有 Serial、Parallel、CMS、G1、ZGC……但万变不离其宗所有 GC 垃圾回收器干的都是同一件事找出活的对象剩下的就是垃圾在想办法腾出内存。换句话说GC 不是在找垃圾而是在救活人。救完之后场地怎么拆、怎么平才是不同回收器的手艺差别。与其死记 G1 的 Region 或 ZGC 的着色指针不如先搞懂什么对象会被救什么对象会被放弃为什么这才是调优、排障、避免内存泄漏的真正起点。看完等于学会点个赞吧