- 博客(35)
- 收藏
- 关注
RSS订阅原创 Docker-Compose容器编排技术
Docker-Compose，是Docker中用于定义和运行多容器应用程序的工具通过Compose可以使用一个YML文件来配置应用程序需要的所有服务通过使用一个命令，就可以从YML文件中创建并启动所有服务。
2025-06-10 11:16:28
132
原创 Docker容器转换为镜像
容器转换镜像 docker commit优点:简单快速，一条命令可得到想要的新镜像不足:无法查看镜像的构建历史不适用于版本控制，不适用自动化部署未完待续。。。
2025-06-07 14:43:49
186
原创 Docker端口映射
注意:"宿主机服务端口:"部分若省略，宿主机会采用随机端口号和容器端口完成映射。cd /var/lib/docker/containers/容器ID。2)外部机器能够访问docker容器的端口。1)外部机器能够成功连接docker容器。修改"hostconfig.json'搜索"PortBindings'重启docker服务，重启容器。
2025-06-05 15:55:28
274
原创 Docker核心知识
镜像(Image)和容器(container)的关系，就和00P设计中"类"和"对象"的关系类似，镜像是模板，容器是镜像运行时的实例，一个镜像可以被多次创建为不同容器。-d(daemon)守护进程运行容器(exit退出交互模式后容器仍运行)，针对一些自带运行进程的应用:若本地仓库没有对应镜像会自动从远程仓库下载，否则出错!镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外还包含了一些运行时的配置参数(如环境变量、用户等)。镜像构建完成后，可以很容易的在当前宿主机上运行。
2025-06-02 18:18:36
326
原创 Spring Boot 项目中常用的 Maven 插件及命令
这些插件和命令可以帮助您更高效地开发和维护 Spring Boot 项目。：打包可执行 JAR/WAR、运行应用、构建 Docker 镜像等。- 构建 Docker 镜像 (需要 Docker 环境)- 更新 properties 中的版本号。- 运行 Spring Boot 应用。- 运行 Spring Boot 应用。- 清理 target 目录。- 构建 Docker 镜像。- 运行所有测试包括集成测试。：构建普通 JAR 文件。- 复制依赖到指定目录。- 运行指定测试方法。- 查看有效 POM。
2025-05-23 10:49:48
786
原创 JDK 1.8 生产环境遇到 java.lang.VerifyError 异常时的排查流程和解决方案
Maven/Gradle的编译插件版本必须与JDK版本匹配。编译版本不兼容（如用JDK 11编译，JDK 8运行）ASM 7.x+ 生成的字节码可能与JDK 8不兼容。动态生成的字节码错误（如ASM、CGLIB）：通过类文件版本和字节码分析找到违规操作。，必须确保从源码到字节码的全链路一致性！：统一编译环境 + 修复字节码生成逻辑。在 JDK 1.8 生产环境中，：构建时验证 + 版本约束。可能掩盖其他潜在问题。
2025-05-21 17:31:41
798
原创 JDK 1.8 生产环境遇到 java.lang.NoSuchMethodError 异常时的排查流程和解决方案
传递性依赖（transitive dependencies）才是常见冲突源。，通常由依赖冲突或版本不一致引起。：通过依赖树和类加载信息找到冲突版本。在 JDK 1.8 生产环境中，子模块可能覆盖父POM的依赖版本。新版本可能引入其他兼容性问题。，需通过严格的依赖管理杜绝！：依赖约束 + 构建时检查。缺失的方法名和签名（如。表示无参void方法）：统一依赖或添加兼容层。
2025-05-21 17:23:07
459
原创 JDK 1.8 生产环境遇到 java.lang.VirtualMachineError 异常时的排查流程和解决方案
该日志包含崩溃时的完整内存映像，必须优先分析。：针对性调整内存/JVM参数或升级JDK。：此类错误表明JVM自身已不稳定，需从。是 JVM 内部错误的总称，表明。：监控 + 压力测试 + 参数加固。在 JDK 1.8 生产环境中，应每次只修改一个参数并观察效果。部分是否有死锁或大量阻塞。，系统OOM会导致进程被。日志确定具体错误类型。JVM OOM会抛出。
2025-05-21 14:42:27
708
原创 JDK 1.8 生产环境遇到 java.lang.UnsupportedClassVersionError 异常时的排查流程和解决方案
即使运行时使用JRE 8，编译仍可能用了高版本JDK。推荐使用Docker固化构建和运行时环境。第三方库可能依赖高版本JDK编译的组件。：统一编译环境 + 排除高版本依赖。在 JDK 1.8 生产环境中，：通过类文件版本号确认问题根源。，否则可能使用高版本API。：构建验证 + 环境隔离。
2025-05-21 14:27:58
771
原创 JDK 1.8 生产环境遇到 java.lang.ClassNotFoundException 异常时的排查流程和解决方案
编译时存在但运行时缺失（通常是加载失败后的二次调用）：通过类加载日志和路径检查确认类缺失原因。：构建验证 + 启动检查 + 环境一致性。Web容器中不同应用的类加载器是隔离的。：修正类路径/修复依赖/调整加载方式。，需确保从开发到部署的全链路一致性！范围的依赖不会打包到最终部署包中。在 JDK 1.8 生产环境中，：检查 bundle 依赖。：明确尝试加载不存在的类。（Linux区分大小写）
2025-05-21 14:17:20
856
原创 JDK 1.8 生产环境中遇到 java.lang.NoClassDefFoundError 异常时的排查流程和解决方案
Web容器（如Tomcat）中不同WEB-APP的类加载器隔离可能导致问题。：编译时存在，运行时缺失（通常是依赖冲突或加载失败），需确保开发/测试/生产环境的全链路一致性！：明确尝试加载不存在的类（通常是配置错误）：通过类加载日志和依赖分析确定缺失根源。可能引入新的兼容性问题，应先通过。在 JDK 1.8 生产环境中，：修正类路径/排除冲突/修复打包。：依赖一致性检查 + 构建验证。类路径，特别是容器化环境。
2025-05-21 14:04:46
921
原创 JDK 1.8 生产环境中遇到 java.lang.IllegalArgumentException: GC triggered before VM initialized 异常时的排查流程和解决方案
-Xmx | ≤ 容器内存限制的80% || -XX:+UseG1GC | 不可与其他GC算法共用 |指定了矛盾的 GC 参数组合（如同时启用 Parallel GC 和 G1 GC）。：JVM 启动参数配置存在冲突，导致堆内存管理无法正常初始化。：检查参数冲突 + 内存设置合理性。：修正矛盾参数 + 适配运行环境。后果：JVM启动崩溃或性能极差。正确做法：只启用一种GC算法。（需预留OS和其他进程）。：启动验证 + 文档规范。
2025-05-21 10:41:17
726
原创 JDK 1.8 生产环境中遇到 java.lang.StackOverflowError 异常时的排查流程和解决方案
后果：32位JVM中可能耗尽虚拟内存地址空间（每个线程栈占用连续内存）。：修复递归逻辑 + 合理设置栈大小。在 JDK 1.8 生产环境中，：栈空间是线程独占资源，需在。：代码审查 + 栈深度监控。
2025-05-21 10:26:30
789
原创 JDK 1.8 生产环境中遇到 OutOfMemoryError: GC overhead limit exceeded 异常时的排查流程和解决方案
若单次Full GC时间 > 1秒或频率 > 5次/分钟，需优化。长期 >90% 且每次GC释放 <5%，表明对象存活率过高。：监控 + 压测 + 代码审查（重点检查集合和缓存）。（存活时间过长的对象本应在Young GC被回收）。：优化GC策略 + 修复问题代码 + 限制资源使用。后果：延长Full GC停顿时间，可能使问题恶化。：此异常表明GC已无法有效回收内存，需从。应用吞吐量（TPS/QPS）是否恢复。后果：掩盖问题，最终导致进程卡死。（如日志消息、缓存条目）。（如 GCeasy）。
2025-05-21 10:11:35
537
原创 JDK 1.8 生产环境中遇到 OutOfMemoryError: Unable to create new native thread 异常时的排查流程和解决方案
定位：通过jstack和系统工具确认线程泄漏点解决：调整系统限制 + 优化线程池 + 修复泄漏代码预防：监控线程数 + 限制资源 + 代码审查核心原则：控制线程生命周期，避免无限制创建！
2025-05-21 09:58:43
787
原创 JDK 1.8 生产环境遇到 OutOfMemoryError: Direct buffer memory 异常时的排查流程和解决方案
或第三方库（如 Netty）申请，不受 JVM 堆内存管理，需特殊处理。（安装 Buffer Pools 插件）。：修复泄漏 + 显式限制 + 池化分配。：NMT + 代码审查 + 线程分析。这类内存通常由 NIO 的。在 JDK 1.8 生产环境中，：未关闭的流或 Channel。：监控 + 压测 + 代码规范。：直接内存需手动管理，务必确保。会影响性能，仅作为临时手段。：本地代码申请的内存未释放。，可能导致堆外内存失控。（如 Netty 的。⚠️ 警告：频繁调用。
2025-05-21 09:47:27
595
原创 JDK 1.8 生产环境遇到 OutOfMemoryError: Metaspace 异常时的排查流程和解决方案
内存耗尽，存储的类元数据（如类信息、方法字节码等）超过了限制。如 Hibernate 的字节码增强、Spring AOP 的 CGLIB 代理。使用工具（如 JMeter）模拟高频率类加载场景，观察元空间增长是否平稳。：JRebel、Spring Boot DevTools 频繁重载类。：元空间 OOM 本质是类元数据管理问题，需从类加载生命周期入手根治！后果：元空间可能耗尽系统内存，触发 OOM Killer。：动态代理（如 CGLIB）、反射生成的类。：限制元空间大小 + 修复类加载泄漏。
2025-05-21 09:37:35
630
原创 JDK 1.8抛出OutOfMemoryError: Java heap space 异常时的排查流程和解决方案
异常时，需通过系统化的步骤定位和解决问题。第三方库的内存泄漏（如某些框架的 Session 未销毁）。后果：延长 Full GC 停顿时间，可能掩盖泄漏问题。静态 Map/Lists 未清理（如全局缓存）。：Heap Dump + MAT 分析泄漏对象。非预期的对象引用链（如静态集合未清理）。：修复代码 + 合理设置 JVM 参数。未关闭的资源（数据库连接、文件流）。：监控 + 压测 + 代码审查。重复的类实例（如缓存、集合）。报告（MAT 自动生成）。（Full GC 次数）。
2025-05-20 17:03:22
613
原创 生产环境中，是否需要进行 JVM 调优的判断方法和关键步骤
应用 QPS/TPS 下降，CPU 利用率却很高（可能因 GC 线程抢占资源）。P99 响应时间明显增加，尤其伴随 GC 停顿时间波动。：监控历史趋势，设置告警规则（如 FGC 频率突增）。：吞吐量、延迟、内存占用不可兼得，需按业务需求权衡。）> 100ms（对低延迟应用需 <50ms）。检查系统级指标（CPU、内存、IO）。：直观查看堆内存、线程、类加载情况。（如“听说 G1 性能好”就切换）。（如内存泄漏未修复，仅增大堆内存）。（老年代使用率）长期 >90%。（默认 8）优化对象晋升策略。
2025-05-20 16:31:41
928
原创 生产环境中，监控线程大小和线程数以及-Xss 参数配置建议
在 JDK 1.8 生产环境中，监控线程大小和线程数以及合理配置。参数是优化 JVM 性能的关键步骤。，对于高并发服务（如 HTTP 服务器），默认 1MB 可能过度分配。线程数 × 栈大小 ≤ 可用内存的 20%~30% → 内存合理。可减少内存占用，但需测试栈深度是否足够。：100 个线程 × 1MB =检查栈大小是否生效。，通过压测验证稳定性。（平衡内存和栈深度）
2025-05-20 15:08:18
476
原创 生产环境中使用 Parallel GC（吞吐量优先垃圾回收器）时，是否需要显式设置 -XX:ParallelGCThreads
不影响 Full GC），需改用 G1/CMS 或优化堆大小。（Young GC 总时间）高但单次耗时短 → 无需调整。若单次 Young GC 耗时过长 → 尝试增加线程数。：监控数据（GC 时间、CPU 使用率）而非盲目猜测。需手动优化线程数以匹配物理核心数（而非逻辑核心）。= 逻辑 CPU 核心数（包括超线程）。），确保 GC 线程未导致应用线程饥饿。（避免 GC 线程占用过多 CPU）。增加线程数可能加速垃圾回收（需监控。，但需在容器或高竞争环境中显式设置。）和对象生命周期比调整线程数更重要。
2025-05-20 14:46:34
822
原创 生产环境添加-XX:+HeapDumpOnOutOfMemoryError参数后JVM 默认生成的 Heap Dump 文件（内存快照）路径
Heap Dump 文件大小通常接近 JVM 堆的最大值（如。如果程序是通过命令行启动的，默认路径通常是执行。：确保目标目录有足够空间，否则会生成失败。并确保目录可写，是生产环境的基本要求。：自动替换为时间戳（避免文件名冲突）。指定路径，否则容器重启后文件丢失。参数时，如果没有显式指定路径 (：永远不要依赖默认路径！：确保 JVM 有写入权限（如。：推荐，支持可视化分析内存泄漏。Heap Dump 会生成在。时可能生成 4GB 文件）。：自动替换为进程 PID。)，JVM 默认生成的。
2025-05-20 14:37:32
348
原创 生产环境直接内存（-XX:MaxDirectMemorySize）默认与-Xmx一致，为什么还需要显式限制？
的值限制直接内存，但部分第三方库（如 Netty、gRPC）或 JNI 代码可能绕过 JVM 管理，直接通过。若配置不当（如未正确释放池化内存），可能导致直接内存泄漏。显式限制是一种防御措施，防止代码中未预期的直接内存分配（如误用 NIO 或第三方库）引发系统性风险。通过独立设置，明确划分两者的配额（例如堆内存 4G + 直接内存 1G），确保系统资源分配可控。：生产环境中所有内存区域（堆、元空间、直接内存等）均应显式设限，确保资源可控和故障可追溯。堆内存未满时，直接内存已耗尽，抛出。
2025-05-20 14:28:14
355
原创 生产环境元空间（Metaspace）的推荐配置值及调优建议
在 JDK 1.8 的生产环境中，元空间（Metaspace）的配置对应用稳定性至关重要。最终值需根据实际应用类加载行为调整，尤其在频繁动态生成类的场景中（如Groovy、字节码增强框架）。若类加载器（如Tomcat的WebAppClassLoader）被回收，其加载的类才能被卸载。：默认初始值较小，可能导致应用启动时频繁触发元空间扩容（伴随Full GC）。类加载器泄漏或动态生成类（如Groovy脚本）可能导致元空间无限增长。使用动态代理（如CGLIB）、反射、热部署（如JRebel）。
2025-05-20 14:21:17
501
原创 生产环境堆内存调整
大数据处理（Spark、Flink）、缓存（EhCache、Hazelcast）、序列化（Protobuf、Kryo）。延长 Full GC 停顿时间（Parallel GC 的 Full GC 是单线程）。堆转储（Heap Dump）分析显示大量对象堆积（如缓存未清理、集合未释放）。应用处理的缓存、数据集（如数据库查询结果）、会话状态等规模显著增加。低于容器内存限制（预留 20% 给 OS 和其他进程）。列）长期高于 90%，频繁触发 Full GC（（年轻代）或切换 GC 算法（如 G1）。
2025-05-20 11:32:42
585
原创 生产环境JVM参数配置指南
XX:MaxDirectMemorySize=1g # 默认与-Xmx一致，需显式限制。-XX:G1HeapRegionSize=4m # 区域大小（建议4-32M）-XX:MaxMetaspaceSize=512m # 防止元空间无限增长。-Xmn2g # 年轻代占堆的1/3到1/2（根据对象生命周期调整）-Xms4g -Xmx4g # 初始堆=最大堆（避免动态调整开销）-XX:MetaspaceSize=256m # 初始大小。
2025-05-20 11:20:11
389
原创 G1 GC（Garbage-First Garbage Collector）原理详解
统计各 Region 的存活对象比例，排序回收价值（Garbage-First）。：标记 GC Roots 直接关联的对象（与 Young GC 同步执行）。动态调整 Region 的角色，避免传统分代 GC 的固定比例限制。存活对象被复制到新的 Survivor 区（或晋升到 Old 区）。：通过选择回收价值高的 Region（垃圾比例高），最大化回收效率。：标记 Eden 和 Survivor 区的存活对象。：新生代和老代的大小不固定，由 G1 自动调整。清空 Eden 和旧的 Survivor 区。
2025-05-15 10:13:43
639
原创 Parallel GC（并行垃圾回收器）原理详解
回收完成后，Eden 和 From Survivor 被清空，From 和 To Survivor 角色交换。：将存活对象复制到 To Survivor 区（如果 To Survivor 空间不足，则直接晋升到老年代）。：多个 GC 线程并行扫描 Eden 和 From Survivor 区，标记存活对象。：每次 Minor GC 后，存活对象的年龄 +1，达到阈值（默认 15）则晋升老年代。，G1 GC 成为默认回收器，但 Parallel GC 仍然可用。：多个线程同时进行标记和整理，减少停顿时间。
2025-05-15 09:39:13
836
转载 SpringBoot自动装配
SpringBoot自动装配 spring支持两种bean的配置方式：基于xml文件和JavaConfig 主启动类上的注解@SpringBootApplication @SpringBootApplication里有三个重要注解 @SpringBoo...
2022-04-07 09:48:44
241
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人