企业官网建设流程全解析

ssh蒙语网站开发,数据分析,创意logo图片大全,手机app网站模板1. 垃圾回收基础理论 问题#xff1a;什么是垃圾回收#xff1f;为什么需要垃圾回收#xff1f; 详细解答#xff1a; 垃圾回收定义 垃圾回收#xff08;Garbage Collection#xff0c;GC#xff09;是自动内存管理机制#xff0c;负责识别和回收不再使用的对象所占…1. 垃圾回收基础理论问题什么是垃圾回收为什么需要垃圾回收详细解答垃圾回收定义垃圾回收Garbage CollectionGC是自动内存管理机制负责识别和回收不再使用的对象所占用的内存空间。为什么需要GC手动内存管理的问题C/C需要手动malloc/free容易出现内存泄漏野指针问题导致程序崩溃双重释放造成内存损坏开发效率低需要时刻关注内存释放GC的优势自动回收不再使用的对象避免内存泄漏和野指针提高开发效率程序更加健壮可靠GC的核心问题三个基本问题哪些内存需要回收→ 对象是否存活判断什么时候回收→ GC触发条件如何回收→ 垃圾回收算法2. 对象存活判断算法问题如何判断一个对象是否可以被回收详细解答引用计数法Reference Counting原理对象添加引用计数器 引用1被引用时 引用-1引用失效时 引用0可回收优点实现简单判定效率高实时性好引用计数为0立即回收致命缺陷循环引用publicclassCircularReference{publicObjectinstancenull;publicstaticvoidmain(String[]args){CircularReferenceobj1newCircularReference();CircularReferenceobj2newCircularReference();// 循环引用obj1.instanceobj2;obj2.instanceobj1;obj1null;obj2null;// 两个对象互相引用引用计数永远不为0// 但实际上已经无法访问造成内存泄漏}}Python的解决方案使用引用计数 标记清除解决循环引用JVM没有采用此方案可达性分析算法Reachability Analysis原理从GC Roots对象作为起点向下搜索 搜索路径称为引用链Reference Chain 对象到GC Roots没有任何引用链相连 → 不可达 → 可回收GC Roots对象包括虚拟机栈中引用的对象publicvoidmethod(){ObjectobjnewObject();// obj是GC Root}方法区中类静态属性引用的对象publicclassTest{publicstaticObjectstaticObjnewObject();// staticObj是GC Root}方法区中常量引用的对象publicclassTest{publicstaticfinalObjectCONST_OBJnewObject();// CONST_OBJ是GC Root}本地方法栈中JNI引用的对象nativevoidnativeMethod();// native方法中引用的对象JVM内部引用基本类型对应的Class对象异常对象系统类加载器synchronized持有的对象JMXBean、JVMTI中注册的回调、本地代码缓存等可达性分析示例GC Roots ├─ Object A ── Object C ├─ Object B ── Object D ── Object E │ └─ Object F Object G ── Object H (互相引用但不可达) 结论 - A, B, C, D, E, F 可达存活 - G, H 不可达可回收引用类型详解强引用Strong ReferenceObjectobjnewObject();// 强引用// 只要强引用存在永远不会被回收// 宁可OOM也不回收软引用Soft ReferenceSoftReferencebyte[]softRefnewSoftReference(newbyte[1024*1024]);// 内存充足不回收// 内存不足回收OOM前// 应用场景缓存MapString,SoftReferenceBitmapimageCachenewHashMap();弱引用Weak ReferenceWeakReferenceObjectweakRefnewWeakReference(newObject());// 无论内存是否充足GC时一定回收// 生命周期下次GC前// 应用场景WeakHashMapWeakHashMapKey,ValuecachenewWeakHashMap();虚引用Phantom ReferenceReferenceQueueObjectqueuenewReferenceQueue();PhantomReferenceObjectphantomRefnewPhantomReference(newObject(),queue);// 无法通过虚引用获取对象// 唯一目的对象被回收时收到系统通知// 应用场景堆外内存回收DirectByteBuffer引用强度比较强引用 软引用 弱引用 虚引用对象的自我拯救finalize()方法机制publicclassFinalizeEscapeGC{publicstaticFinalizeEscapeGCSAVE_HOOKnull;publicvoidisAlive(){System.out.println(I am still alive!);}Overrideprotectedvoidfinalize()throwsThrowable{super.finalize();System.out.println(finalize method executed!);// 自我拯救重新建立引用FinalizeEscapeGC.SAVE_HOOKthis;}publicstaticvoidmain(String[]args)throwsInterruptedException{SAVE_HOOKnewFinalizeEscapeGC();// 第一次拯救成功SAVE_HOOKnull;System.gc();Thread.sleep(500);// 等待finalize执行if(SAVE_HOOK!null){SAVE_HOOK.isAlive();// 输出I am still alive!}else{System.out.println(I am dead!);}// 第二次拯救失败finalize只执行一次SAVE_HOOKnull;System.gc();Thread.sleep(500);if(SAVE_HOOK!null){SAVE_HOOK.isAlive();}else{System.out.println(I am dead!);// 输出这个}}}finalize()的问题执行时间不确定低优先级Finalizer线程性能开销大只执行一次可能导致对象复活架构师建议避免使用finalize()使用try-finally或try-with-resourcesJDK 9引入Cleaner机制替代finalize()3. 垃圾回收算法详解问题JVM中有哪些垃圾回收算法各有什么优缺点详细解答标记-清除算法Mark-Sweep工作流程1. 标记阶段标记所有需要回收的对象 2. 清除阶段统一回收被标记的对象示意图回收前[对象A][对象B][对象C][对象D][对象E] 标记后[对象A][×对象B][对象C][×对象D][对象E] 清除后[对象A][ ][对象C][ ][对象E]优点实现简单不需要移动对象缺点效率问题标记和清除效率都不高空间问题产生大量内存碎片应用场景CMS收集器的老年代回收内存碎片问题示例// 假设需要分配连续100MB内存byte[]largeArraynewbyte[100*1024*1024];// 虽然总空闲内存100MB但没有连续的100MB空间// 导致分配失败触发Full GC或OOM标记-复制算法Mark-Copy工作流程1. 将内存分为两块From区和To区 2. 使用From区分配对象 3. GC时将From区存活对象复制到To区 4. 清空From区 5. 交换From和To的角色示意图From区[A][B][C][D][E] To区[空] ↓ GCB、D为垃圾 From区[空] To区[A][C][E]HotSpot的Eden Survivor实现新生代分配Eden:Survivor0:Survivor1 8:1:1 正常情况 Eden Survivor0 → Survivor1存活对象10% 极端情况 存活对象Survivor容量 → 老年代担保分配优点实现简单运行高效没有内存碎片缺点空间浪费可用内存缩小为原来的一半存活率高时效率降低需要复制大量对象应用场景新生代回收对象存活率低约10%代码示例// 新生代对象分配publicclassYoungGenAllocation{privatestaticfinalint_1MB1024*1024;publicstaticvoidmain(String[]args){byte[]allocation1newbyte[2*_1MB];// Edenbyte[]allocation2newbyte[2*_1MB];// Edenbyte[]allocation3newbyte[2*_1MB];// Eden// Eden空间不足触发Minor GC// allocation1、2、3晋升到老年代byte[]allocation4newbyte[4*_1MB];}}标记-整理算法Mark-Compact工作流程1. 标记阶段标记存活对象 2. 整理阶段让所有存活对象向内存一端移动 3. 清理阶段清理边界外的内存示意图标记后[A][×B][C][×D][E][×F] 整理后[A][C][E][ ] ↑存活对象 ↑可分配空间两种实现策略1. Move策略移动存活对象// 伪代码for(Objectobj:liveObjects){moveToCompactArea(obj);updateReferences(obj);// 更新所有引用}2. Slide策略滑动压缩// 伪代码// 三次扫描// 1. 计算新地址// 2. 更新引用// 3. 移动对象优点没有内存碎片空间利用率高适合老年代存活率高缺点效率问题需要移动大量对象并更新引用暂停时间长Stop The World应用场景Serial Old收集器Parallel Old收集器分代收集理论分代假说Generational Hypothesis弱分代假说绝大多数对象都是朝生夕灭98%的对象在第一次GC后被回收强分代假说熬过多次GC的对象越难消亡长时间存活的对象生命周期会更长跨代引用假说跨代引用相对于同代引用占极少数存在互相引用关系的对象倾向于同时生存或消亡分代设计堆内存 ├── 新生代Young Generation │ ├── Eden区80% │ ├── Survivor0区10% │ └── Survivor1区10% └── 老年代Old Generation回收策略Minor GC新生代GC触发条件Eden区满回收算法复制算法频率高秒级停顿时间短毫秒级Major GC老年代GC触发条件老年代满或晋升失败回收算法标记-清除或标记-整理频率低分钟-小时级停顿时间长可能达到秒级Full GC全堆GC触发条件老年代空间不足元空间不足System.gc()调用CMS GC出现promotion failed、concurrent mode failure回收范围新生代老年代元空间停顿时间最长对象晋升规则1.长期存活对象进入老年代-XX:MaxTenuringThreshold15// 默认15次2.大对象直接进入老年代-XX:PretenureSizeThreshold1048576// 1MB3.动态年龄判定// Survivor空间中相同年龄所有对象大小总和 Survivor空间一半// 年龄该年龄的对象直接进入老年代4.空间分配担保// Minor GC前检查老年代最大连续空间 新生代所有对象总大小// 是安全执行Minor GC// 否Full GC架构师实战经验分代收集优化要点根据对象生命周期特征调整新生代大小合理设置晋升阈值避免频繁Full GC大对象使用对象池或直接分配到老年代监控晋升速率评估内存配置合理性4. 垃圾收集器详解问题JVM有哪些垃圾收集器各有什么特点和适用场景详细解答收集器总览新生代收集器 - Serial - ParNew - Parallel Scavenge 老年代收集器 - Serial Old - Parallel Old - CMS 全堆收集器 - G1 - ZGCJDK 11 - ShenandoahJDK 12Serial / Serial Old收集器特点单线程收集器收集时必须暂停所有工作线程Stop The World简单高效单线程下没有线程交互开销工作流程用户线程 → [暂停] → Serial GC → [继续] ↓ 单线程回收参数配置-XX:UseSerialGC# 新生代Serial 老年代Serial Old适用场景Client模式桌面应用单核CPU或内存较小的环境对停顿时间不敏感的应用ParNew收集器特点Serial的多线程版本新生代并行老年代串行与CMS配合使用工作流程用户线程 → [暂停] → ParNew GC多线程 → [继续]参数配置-XX:UseParNewGC# 使用ParNew-XX:ParallelGCThreads4# GC线程数通常CPU核心数线程数配置建议CPU核心数 8GC线程数 CPU核心数 CPU核心数 8GC线程数 3 (5 * CPU核心数 / 8)适用场景多核CPU环境配合CMS使用Parallel Scavenge / Parallel Old收集器特点吞吐量优先收集器新生代和老年代都是并行回收自适应调节策略GC Ergonomics关键参数-XX:UseParallelGC# 新生代Parallel Scavenge-XX:UseParallelOldGC# 老年代Parallel Old-XX:MaxGCPauseMillis200# 最大停顿时间毫秒-XX:GCTimeRatio99# 吞吐量大小默认99即1%时间GC-XX:UseAdaptiveSizePolicy# 自适应调节策略吞吐量计算吞吐量 运行用户代码时间 / (运行用户代码时间 GC时间) 例如 运行100分钟GC 1分钟 吞吐量 100 / (100 1) 99%自适应策略// JVM自动调整-新生代大小-Eden与Survivor比例-晋升老年代对象年龄阈值// 目标在停顿时间和吞吐量之间找到最优解适用场景后台计算任务批处理、科学计算不需要太多交互的应用对停顿时间不敏感但要求高吞吐量CMS收集器Concurrent Mark Sweep设计目标获取最短停顿时间互联网站或B/S系统的服务端工作流程四个阶段1. 初始标记Initial Mark- STW标记GC Roots直接关联的对象 速度快停顿时间短2. 并发标记Concurrent Mark- 并发从GC Roots遍历整个对象图 与用户线程并发执行 时间最长但不停顿3. 重新标记Remark- STW修正并发标记期间变动的对象标记记录 使用增量更新算法 停顿时间略长于初始标记4. 并发清除Concurrent Sweep- 并发清除死亡对象 与用户线程并发执行时间线用户线程: ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ CMS GC: ║ ▒▒▒▒▒▒ ║ ▒▒▒▒ 初始 并发标记 重新 并发清除 标记 标记 ║ STW停顿 ▒ 并发执行参数配置-XX:UseConcMarkSweepGC# 使用CMS-XX:CMSInitiatingOccupancyFraction70# 触发CMS的老年代占用阈值-XX:UseCMSInitiatingOccupancyOnly# 只使用设定的阈值-XX:CMSScavengeBeforeRemark# 重新标记前进行一次Minor GC-XX:UseCMSCompactAtFullCollection# Full GC时进行碎片整理-XX:CMSFullGCsBeforeCompaction5# 多少次Full GC后整理一次优点并发收集低停顿缺点1. CPU资源敏感默认GC线程数 (CPU核心数 3) / 4 4核CPU1个GC线程占用25% CPU 2核CPU1个GC线程占用50% CPU影响严重2. 无法处理浮动垃圾Floating Garbage// 并发标记阶段产生的新垃圾ObjectobjnewObject();// 并发标记开始前存在objnull;// 并发标记期间变为垃圾// 这部分垃圾要等下次GC才能回收3. 内存碎片问题使用标记-清除算法 产生大量内存碎片 可能导致提前触发Full GC4. Concurrent Mode Failure触发原因 - 并发清除期间老年代空间不足以容纳晋升对象 - 预留空间不足CMSInitiatingOccupancyFraction设置过高 后果 - 启用Serial Old收集器进行Full GC - 停顿时间大幅增加 解决方案 - 降低CMSInitiatingOccupancyFraction值 - 增加老年代大小适用场景重视响应速度的应用互联网网站、B/S系统不能容忍长时间停顿的服务G1收集器Garbage First设计目标在延迟可控的情况下获得尽可能高的吞吐量替代CMS收集器核心概念Region堆内存划分为多个大小相等的Region1-32MB Region类型 - Eden区 - Survivor区 - Old区 - Humongous区大对象Region大小的50%工作流程1. 初始标记Initial Mark- STW标记GC Roots直接关联的对象 借用Minor GC的暂停2. 并发标记Concurrent Mark- 并发遍历对象图 使用SATBSnapshot-At-The-Beginning算法3. 最终标记Final Mark- STW处理SATB缓冲区4. 筛选回收Live Data Counting and Evacuation- STW根据停顿时间目标选择回收Region 将选中Region的存活对象复制到空Region 回收旧Region空间关键技术1. Remembered Set记忆集// 记录Region之间的引用关系// 避免全堆扫描// 每个Region维护一个RSetclassRegion{RememberedSetrset;// 记录哪些Region引用了本Region的对象}// Minor GC时只需扫描// - Eden区// - Survivor区// - RSet记录的引用Region2. Collection Set回收集合记录要被回收的Region集合 根据停顿时间目标动态选择 优先回收垃圾最多的RegionGarbage First3. 停顿预测模型// 基于历史数据预测回收时间// 动态选择回收Region数量预测因素-每个Region的垃圾占比-历史回收耗时-复制存活对象的耗时参数配置-XX:UseG1GC# 使用G1-XX:MaxGCPauseMillis200# 最大停顿时间目标-XX:G1HeapRegionSize16m# Region大小-XX:InitiatingHeapOccupancyPercent45# 触发并发GC的堆占用阈值-XX:G1NewSizePercent5# 新生代最小占比-XX:G1MaxNewSizePercent60# 新生代最大占比-XX:ParallelGCThreads8# 并行GC线程数-XX:ConcGCThreads2# 并发GC线程数Mixed GC详解触发条件 1. 并发标记完成 2. 老年代占用达到阈值 回收范围 - 整个新生代 - 部分老年代Region 选择策略 根据停顿时间目标和垃圾占比选择最值得回收的Region优点可预测的停顿时间没有内存碎片复制算法并行与并发结合分代收集但不需要连续空间缺点内存占用高RSet占堆内存约10%-20%执行负载高写屏障维护RSet小堆(4G)性能可能不如CMS适用场景大堆内存4G需要可预测停顿时间替代CMS的生产环境ZGC收集器JDK 11设计目标停顿时间不超过10ms支持TB级堆内存停顿时间不随堆大小增加而增加核心技术1. 着色指针Colored Pointer64位指针布局 [18位未使用][1位Finalizable][1位Remapped] [1位Marked1][1位Marked0][42位对象地址] 通过指针中的标志位标记对象状态2. 读屏障Load Barrier// 每次从堆中读取对象引用时检查并修复指针Objectobjobject.field;// 读屏障检查指针状态// 必要时进行重新映射3. 并发整理使用转发表Forwarding Table 实现对象移动的并发参数配置-XX:UseZGC# 使用ZGC-XX:ZCollectionInterval120# GC间隔秒-XX:ZAllocationSpikeTolerance2# 分配尖峰容忍度适用场景大内存应用100G要求极低延迟10msJDK 11及以上版本架构师选择建议场景推荐收集器理由小堆(2G)低延迟ParNewCMS成熟稳定中大堆(4-64G)G1可预测停顿超大堆(64G)极低延迟ZGC停顿时间10ms批处理高吞吐量Parallel吞吐量最高