Docker环境下SpringBoot程序内存溢出（OOM）问题深度解析与实战调优

文章目录

      • 一、问题背景与现象还原
        • **1. 业务背景**
        • **2. 故障特征**
        • **3. 核心痛点**
        • **4. 解决目标**
      • 二、核心矛盾点分析
        • **1. JVM 与容器内存协同失效**
        • **2. 非堆内存泄漏**
        • **3. 容器内存分配策略缺陷**
      • 三、系统性解决方案
        • **1. Docker 容器配置**
        • 2. JVM参数优化（容器感知配置）
        • **3. Spring Boot 与 Tomcat 优化**
        • 4. 内存泄漏排查工具链
          • 4.1. arthas全局内存仪表盘（`dashboard`）
          • 4.2. arthas内存变化趋势监测（`memory`）
          • 4.3 arthas方法调用追踪（`trace`）
          • 4.4 arthas参数与返回值观察（`watch`）
        • 5.代码层面优化
          • 5.1 内存检测
          • 5.2 对象引用主动置空与生命周期管理
          • 5.3 资源释放标准化
          • 5.4 集合类内存优化
      • 四、典型故障场景复盘
        • 案例：MyBatis缓存导致Metaspace溢出
        • 案例：Netty堆外内存泄漏
      • 五、生产环境最佳实践
      • 六、兜底方案
        • 6.1 通过Semaphore 限制并发量
        • 6.2 实时计算内存使用情况，拦截内存溢出异常
        • 6.3 完整代码
      • 七、总结与思考

一、问题背景与现象还原

某SpringBoot数据平台在支撑ClickHouse海量数据导出时频繁崩溃，核心矛盾如下：

1. 业务背景
  • 单次导出需并发查询十余张视图（2亿~2000万行级数据）
  • 用户频繁选择全字段导出或超宽时间范围筛选，导致单任务数据量激增
2. 故障特征
  • 提交超大请求后，系统在物理内存仅用3.4G/8G时即抛出OOM
  • 报错集中在非堆内存区域（如DirectBuffer、Metaspace），导致Druid连接池、Tomcat线程崩溃
  • 进程完全卡死，必须人工重启恢复
3. 核心痛点
  • 全量数据内存驻留式处理，单任务消耗GB级内存
  • 缺乏内存预警，用户无感知触发崩溃，日均3-5次运维介入
  • 服务中断影响全局业务，技术债务亟待解决
4. 解决目标

① 代码/JVM层优化降低常规内存消耗
② 极端场景下主动熔断任务，提示用户优化查询条件

初始启动命令：

docker run -d \--restart=always \-e JAVA_OPTS="-Xms1024m -Xmx4096m -Duser.timezone=Asia/Shanghai" \-e spring.profiles.active=prd \-p 9999:8080 \-v /app/logs:/app/logs \--name 服务名 \镜像：标签

二、核心矛盾点分析

1. JVM 与容器内存协同失效

  • 现象：-Xmx4096m 仅设置堆内存上限，但未明确容器总内存限制，导致非堆内存（元空间、直接内存、线程栈等）超出容器默认限制，触发 OOM Killer 终止进程。

  • 验证方法

    docker stats --no-stream anesthesia-research  # 查看容器实际内存限制与使用情况
cat /sys/fs/cgroup/memory/memory.stat         # 分析容器内存分布（包括缓存和RSS）
2. 非堆内存泄漏
  • 元空间泄漏：动态类加载未释放（如频繁反射、Spring AOP 代理类生成）。
  • 直接内存泄漏：NIO 缓冲区未释放（如 Netty、大文件操作未调用 Cleaner）。
  • 线程栈累积：默认线程栈大小 1MB，高并发场景下总占用可能超过容器剩余内存。
3. 容器内存分配策略缺陷
  • 未启用容器感知：旧版 Java 或未配置 -XX:+UseContainerSupport，导致 JVM 按宿主机内存分配堆，挤占非堆内存空间。
  • 静态分配堆内存：-Xmx 固定值无法动态适配容器内存变化，易导致整体内存超限。

三、系统性解决方案

1. Docker 容器配置

  • 明确内存限制

    docker run

    中增加容器总内存约束（预留 25% 给非堆内存）：

    docker run -d \-m 12g \                         # 容器总内存限制为 12GB（需大于 JVM 堆内存）--memory-swap=12g \              # 禁用 Swap 避免性能下降--restart=always \...其他参数...

  • 监控容器级内存：

    docker stats 服务名  # 实时观察内存占用

在这里插入图片描述
在这里插入图片描述

2. JVM参数优化（容器感知配置）
-e JAVA_OPTS="-XX:+UseContainerSupport          # 启用容器内存感知（关键！）-XX:MaxRAMPercentage=75.0         # 动态分配堆内存占容器总内存的 75%（12G → 9G）-XX:InitialRAMPercentage=75.0     # 初始化堆75%（物理机）-XX:MaxMetaspaceSize=1g      # 限制元空间内存（防止类加载泄漏）-XX:MaxDirectMemorySize=2g        # 限制直接内存（NIO 场景必配）-Xss256k                          # 减少线程栈内存（适合高并发）-XX:+ExitOnOutOfMemoryError-XX:+HeapDumpOnOutOfMemoryError    # 自动生成堆转储文件-XX:NativeMemoryTracking=summary"
  • 关键调整：移除-Xmx，采用容器感知的百分比分配策略，允许JVM动态适配内存限制
  • 线程优化：将默认1MB线程栈缩小至256k，降低高并发场景下的内存消耗

优化后的启动命令：

docker run -d    --restart=always  -m 12g  --memory-swap=16g     -e JAVA_OPTS="-XX:+UseContainerSupport 
-XX:MaxRAMPercentage=75.0 
-XX:MaxMetaspaceSize=1g 
-XX:MaxDirectMemorySize=2g  
-Xss256k  
-XX:+UseG1GC--XX:+ExitOnOutOfMemoryError  
-XX:NativeMemoryTracking=summary  
-XX:+UnlockDiagnosticVMOptions  
-XX:+StartAttachListener  
-Duser.timezone=Asia/Shanghai"     
-e spring.profiles.active=prd     
-p 9999:8080     -v /app/logs:/app/logs     --name 服务名 镜像：标签
3. Spring Boot 与 Tomcat 优化

  • Tomcat 线程池调整

    （减少线程数及内存占用）：

    -e SERVER_TOMCAT_THREADS_MAX=50 \      # 最大工作线程数（默认 200）
-e SERVER_TOMCAT_ACCEPT_COUNT=50 \     # 等待队列长度（默认 100）
-e SPRING_MAIN_LAZY_INITIALIZATION=true  # 延迟初始化 Bean 减少启动内存

  • 日志框架优化

    ：限制 Logback 异步队列大小，避免日志堆积：

    <!-- logback-spring.xml -->
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender"><queueSize>1024</queueSize>  <!-- 默认 256，过大易导致内存膨胀 -->
</appender>
4. 内存泄漏排查工具链
工具使用场景命令示例
jmap生成堆转储分析大对象jmap -dump:format=b,file=heap.bin <pid>
arthas动态诊断内存泄漏点dashboard + heapdump
NMT追踪Native Memory分配详情jcmd <pid> VM.native_memory detail
Prometheus监控容器/JVM内存趋势配置jmx_exporter+Grafana看板
4.1. arthas全局内存仪表盘（dashboard）

执行命令实时查看内存全景：

dashboard -i 2000  # 每2秒刷新一次

关键指标解读：

  • Heap：堆内存使用率（重点关注eden_space和tenured_gen）
  • Non-Heap：元空间、代码缓存区等非堆内存
  • GC次数与耗时：gc.ps_scavenge.count（Young GC次数）、gc.ps_marksweep.time（Full GC耗时）

在这里插入图片描述

4.2. arthas内存变化趋势监测（memory）

持续追踪内存增长：

memory -t 60 -n 5  # 每60秒采样一次，显示前5名增长对象

典型内存泄漏特征：heap或eden_space持续上涨且无锯齿状回收曲线

4.3 arthas方法调用追踪（trace）

定位高内存消耗的接口：

trace com.example.UserController getUserInfo  # 追踪接口方法调用链路

输出包含：

  • 每个子调用的耗时与内存分配（通过-j参数显示内存变化）
  • 关联的SQL查询或外部服务调用（如发现拼接10万参数的SQL）
4.4 arthas参数与返回值观察（watch）

监控接口入参和返回值对内存的影响：

watch com.example.OrderService createOrder "{params,returnObj}" -x 3  # 展开3层对象结构

典型场景：

  • 大对象参数（如List包含10万元素）
  • 缓存未释放的返回对象（如未设置TTL的缓存）
5.代码层面优化
5.1 内存检测

检测静态方法：

@Slf4j
public class MemoryMonitor {/*** 安全阈值（建议80%）*/private static final double MEMORY_THRESHOLD = 80;public static void isMemoryCritical() {MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();long maxMB = memoryBean.getHeapMemoryUsage().getMax() / (1024 * 1024);long usedMB = memoryBean.getHeapMemoryUsage().getUsed() / (1024 * 1024);double usedPercent = ((double) usedMB / maxMB) * 100;String formatted = String.format("%.2f%%", usedPercent);log.info("当前内存使用情况：最大内存={} MB，已使用内存={} MB", maxMB, usedMB);log.info("当前内存使用百分比={}", formatted); if (usedPercent > MEMORY_THRESHOLD){throw new MemoryThresholdException("内存使用超过安全阈值，请及时处理！");}}
}

专属异常：

/*** MemoryThresholdException : 内存阈值异常** @author zyw* @create 2025-04-11  10:44*/public class MemoryThresholdException extends RuntimeException {public MemoryThresholdException(String message) {super(message);}
}
5.2 对象引用主动置空与生命周期管理

  1. 显式置空无用对象
    通过将不再使用的对象引用设为 null，加速 GC 标记回收：

    List<Object> dataCache = new ArrayList<>();
// 大数据处理完成后清理
dataCache.clear();  // 清空集合内容
dataCache = null;   // 释放集合对象引用

  2. 局部变量作用域控制
    缩小对象生命周期范围，避免长生命周期的变量持有短生命周期对象：

    public void processData() {// 大对象在方法内部创建，方法结束自动回收byte[] buffer = new byte[1024 * 1024]; // ...处理逻辑...
}  // buffer 超出作用域后自动回收
5.3 资源释放标准化

  1. Try-With-Resources 自动关闭
    对实现 AutoCloseable 接口的资源（文件、数据库连接等），强制使用自动关闭语法：

    try (Connection conn = dataSource.getConnection();PreparedStatement stmt = conn.prepareStatement(sql)) {// 执行查询...
}  // 自动调用 close() 释放资源

  2. 线程局部变量清理
    避免 ThreadLocal 内存泄漏，使用后必须调用 remove()：

    ThreadLocal<UserSession> userSession = new ThreadLocal<>();
try {userSession.set(new UserSession());// ...业务逻辑...
} finally {userSession.remove();  // 强制清理线程绑定数据
}
5.4 集合类内存优化

  1. 静态集合使用弱引用
    替换静态 HashMap 为 WeakHashMap，避免缓存对象无法回收：

    // 使用弱引用缓存（Key 无强引用时自动回收）
Map<Long, UserSession> cache = new WeakHashMap<>();

  2. 大容量集合分块处理
    分批处理数据流，避免一次性加载到内存：

    try (BufferedReader reader = new BufferedReader(new FileReader("large.log"))) {String line;while ((line = reader.readLine()) != null) {processLine(line);  // 逐行处理，不缓存全部数据}
}

四、典型故障场景复盘

案例：MyBatis缓存导致Metaspace溢出

某分页查询接口在高并发场景下频繁生成动态代理类，最终触发OutOfMemoryError: Metaspace。通过以下步骤定位：

  1. 日志分析：发现Metaspace使用量持续增长至512MB上限
  2. 堆转储验证：使用MAT工具分析发现org.apache.ibatis.reflection.javassist.JavassistProxyFactory类实例过多
  3. 解决方案：调整MyBatis的localCacheScope为STATEMENT，禁用全局缓存
案例：Netty堆外内存泄漏

某个TCP长连接服务运行24小时后出现OutOfMemoryError: Direct buffer memory，根本原因为未正确释放ByteBuf：

// 错误写法：未调用release()
ByteBuf buf = Unpooled.directBuffer(1024);
// 正确写法
try (ByteBuf buf = PooledByteBufAllocator.DEFAULT.directBuffer(1024)) {// 业务逻辑
} finally {buf.release(); 
}

通过-XX:MaxDirectMemorySize限制直接内存，并通过io.netty.leakDetectionLevel=paranoid开启泄漏检测。

五、生产环境最佳实践

  1. 防御性编程

    • 所有资源类对象（连接池、文件句柄）必须显式关闭
    • 使用WeakHashMap替代强引用缓存，避免内存驻留

  2. 监控体系构建

    # 容器级监控
docker stats --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}"# JVM级监控
jstat -gc <pid> 500  # 每500ms输出GC统计

  3. 混沌工程验证

    • 使用stress-ng工具模拟内存压力：
    stress-ng --vm 2 --vm-bytes 80% --timeout 10m
    • 验证JVM的-XX:+ExitOnOutOfMemoryError是否正常触发进程退出

六、兜底方案

6.1 通过Semaphore 限制并发量

配置：

/*** 限制并发数为1 （这里测试阶段暂设为1，可根据实际硬件配置权衡性能设置）*/
private final Semaphore semaphore = new Semaphore(1);

使用：

        try {// 获取信号量，限制并发semaphore.acquire();} catch (InterruptedException e) {log.error("《==获取信号量时被中断，导出id：{}，异常信息：{}", recordId, e.getMessage());} finally {// 释放信号量semaphore.release(); }
6.2 实时计算内存使用情况，拦截内存溢出异常
@Slf4j
public class MemoryMonitor {/*** 安全阈值（建议80%）*/private static final double MEMORY_THRESHOLD = 80;public static final String MEMORY_THRESHOLD_MESSAGE = "内存使用超过安全阈值，请缩小模板导出筛选范围或减少导出的变量！";public static void isMemoryCritical() {MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();long maxMB = memoryBean.getHeapMemoryUsage().getMax() / (1024 * 1024);long usedMB = memoryBean.getHeapMemoryUsage().getUsed() / (1024 * 1024);double usedPercent = ((double) usedMB / maxMB) * 100;String formatted = String.format("%.2f%%", usedPercent);log.info("当前内存使用情况：最大内存={} MB，已使用内存={} MB", maxMB, usedMB);log.info("当前内存使用百分比={}", formatted);if (usedPercent > MEMORY_THRESHOLD){throw new MemoryThresholdException(MEMORY_THRESHOLD_MESSAGE);}}// 模拟内存溢出测试public static void main(String[] args) {List<byte[]> list = new ArrayList<>();for (int i = 0; i < 50; i++) {isMemoryCritical();// 每次分配100MB内存list.add(new byte[1024 * 1024 * 100]);}}
}
6.3 完整代码
/*** 限制并发数为1 （这里测试阶段暂设为1，可根据实际硬件配置权衡性能设置）*/
private final Semaphore semaphore = new Semaphore(1);@Async("asyncThreadPool")    
public void generateResearchDirectionFilesByTemplate(Long recordId, String fileName) {try {// 获取信号量，限制并发semaphore.acquire();// 异步执行的业务逻辑log.info("《==异步生成Excel文件中，导出申请id：{}==》", recordId);long l1 = System.currentTimeMillis();ExportRecords record = exportRecordsService.getById(recordId);try {String fileUrl = filePath + "/" + recordId + "/" + fileName + "-" + LocalDate.now() + ".xlsx";// 获取模板详情及写入数据Workbook workbook = exportAlgorithm(record.getProjectId(), record.getTemplateId());long l2 = System.currentTimeMillis();log.info("写入Excle耗时：{}", l2 - l1);// 上传到MINIO// 将 Workbook 转换为字节数组输入流ByteArrayOutputStream baos = new ByteArrayOutputStream();workbook.write(baos);byte[] workbookBytes = baos.toByteArray();ByteArrayInputStream bis = new ByteArrayInputStream(workbookBytes);PutObjectArgs args = PutObjectArgs.builder().bucket(minioConfig.getBucketName()).object(fileUrl).stream(bis, bis.available(), -1).contentType("application/vnd.openxmlformats-officedocument.spreadsheetml.sheet").build();minioClient.putObject(args);// 录入文件idrecord.setFileUrl(fileUrl);// 导出状态更新record.setFileStatus(StatusConstant.EXPORT_SUCCESSFULLY);long l4 = System.currentTimeMillis();log.info("《==异步生成Excel文件成功，导出id：{}==》，总耗时：{}", recordId, (l4 - l1));record.setTimeConsuming((l4 - l1));record.setErrorLog("无");} catch (ExcleException | MemoryThresholdException e) { // 自定义异常拦截预期报错record.setFileStatus(StatusConstant.EXPORT_FAILURE);record.setErrorMessage(e.getMessage());} catch (OutOfMemoryError e) {  // 拦截预期之外的内存溢出异常record.setFileStatus(StatusConstant.EXPORT_FAILURE);record.setErrorMessage(MemoryMonitor.MEMORY_THRESHOLD_MESSAGE);} catch (Exception e) {   // 程序报错拦截e.printStackTrace();record.setFileStatus(StatusConstant.EXPORT_FAILURE);if (Objects.isNull(e.getMessage())) {record.setErrorLog("无报错日志");} else {record.setErrorLog(e.getMessage().length() <= 500 ? e.getMessage() : e.getMessage().substring(0, 500));}long l5 = System.currentTimeMillis();record.setTimeConsuming((l5 - l1));log.info("《==异步生成Excel文件失败，导出id：{}，异常信息：{}", recordId, e.getMessage());record.setErrorMessage(AnesthesiaResultCode.EXPORT_PROGRAM_ERROR.getMessage());} finally {// 修改导出记录下载状态exportRecordsService.updateById(record);// 内存清理System.gc();}} catch (InterruptedException e) {log.error("《==获取信号量时被中断，导出id：{}，异常信息：{}", recordId, e.getMessage());} finally {semaphore.release(); // 释放信号量}
}

七、总结与思考

在容器化Java应用的运维中，内存管理需要从四个维度综合考量：

  1. 容器资源配额：合理设置Swap空间，平衡性能与稳定性
  2. JVM内存模型：理解堆/非堆内存的分配策略，避免参数冲突
  3. 应用代码质量：通过静态扫描（SonarQube）和动态分析（Arthas）预防泄漏
  4. 监控告警体系：建立容器/JVM/APM三层监控，实现异常早发现

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.mzph.cn/bicheng/77869.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

【PGCCC】Postgres MVCC 内部：更新与插入的隐性成本

【PGCCC】Postgres MVCC 内部：更新与插入的隐性成本

为什么 Postgres 中的更新操作有时感觉比插入操作慢&#xff1f;答案在于 Postgres 如何在后台管理数据版本。 Postgres 高效处理并发事务能力的核心是多版本并发控制&#xff08;MVCC&#xff09;。 在本文中&#xff0c;我将探讨 MVCC 在 Postgres 中的工作原理以及它如何影响…
阅读更多...
Docker使用、容器迁移

Docker使用、容器迁移

Docker 简介 Docker 是一个开源的容器化平台&#xff0c;用于打包、部署和运行应用程序及其依赖环境。Docker 容器是轻量级的虚拟化单元&#xff0c;运行在宿主机操作系统上&#xff0c;通过隔离机制&#xff08;如命名空间和控制组&#xff09;确保应用运行环境的一致性和可移…
阅读更多...
c#清理释放内存

c#清理释放内存

虽然c#具有内存管理和垃圾回收机制&#xff0c;但是在arcobjects二次开发嵌入到arcgis data reviewet还会报内存错误。需要强制清理某变量内存方法如下: 1设置静态函数ReleaseCom函数 public static void ReleaseCom(object o) { try{System.Runtime.InteropServices.Marsh…
阅读更多...
Linux:进程:进程控制

Linux:进程:进程控制

进程创建 在Linux中我们使用fork函数创建新进程&#xff1a; fork函数 fork函数是Linux中的一个系统调用&#xff0c;用于创建一个新的进程&#xff0c;创建的新进程是原来进程的子进程 返回值&#xff1a;如果子进程创建失败&#xff0c;返回值是-1。如果子进程创建成功&a…
阅读更多...
day1-小白学习JAVA---JDK安装和环境变量配置（mac版）

day1-小白学习JAVA---JDK安装和环境变量配置（mac版）

JDK安装和环境变量配置 我的电脑系统一、下载JDK1、oracle官网下载适合的JDK安装包&#xff0c;选择Mac OS对应的版本。 二、安装三、配置环境变量1、终端输入/usr/libexec/java_home -V查询所在的路径&#xff0c;复制备用2、输入ls -a3、检查文件目录中是否有.bash_profile文…
阅读更多...
Python项目--基于机器学习的股票预测分析系统

Python项目--基于机器学习的股票预测分析系统

1. 项目介绍 在当今数字化时代&#xff0c;金融市场的数据分析和预测已经成为投资决策的重要依据。本文将详细介绍一个基于Python的股票预测分析系统&#xff0c;该系统利用机器学习算法对历史股票数据进行分析&#xff0c;并预测未来股票价格走势&#xff0c;为投资者提供决策…
阅读更多...
计算机视觉与深度学习 | 基于YOLOv8与光流法的目标检测与跟踪（Python代码）

计算机视觉与深度学习 | 基于YOLOv8与光流法的目标检测与跟踪（Python代码）

===================================================== github：https://github.com/MichaelBeechan CSDN：https://blog.csdn.net/u011344545 ===================================================== 目标检测与跟踪 关键实现逻辑检测-跟踪协作机制‌特征点选择策略‌运动…
阅读更多...
Java集合及面试题学习

Java集合及面试题学习

知识来源沉默王二、小林coding、javaguide 1、ArrayList list.add("66") list.get(2) list.remove(1) list.set(1,"55") List<String> listnew ArrayList<>(); 底层是动态数组 添加元素流程&#xff1a;判断是否扩容&#xf…
阅读更多...
OSPF --- LSA

OSPF --- LSA

文章目录 一、OSPF LSA&#xff08;链路状态通告&#xff09;详解1. LSA通用头部2. OSPFv2 主要LSA类型a. Type 1 - Router LSAb. Type 2 - Network LSAc. Type 3 - Summary LSAd. Type 4 - ASBR Summary LSAe. Type 5 - AS External LSAf. Type 7 - NSSA External LSA 3. LSA泛…
阅读更多...
Spring Boot 框架介绍及 Spring Boot 与 Spring 实现对比

Spring Boot 框架介绍及 Spring Boot 与 Spring 实现对比

在日常 Java Web 开发中&#xff0c;Spring 框架几乎是绕不开的技术体系。传统的 Spring 项目因其灵活强大而被广泛应用&#xff0c;但随着项目规模扩大与业务复杂度提升&#xff0c;XML 配置繁琐、部署复杂等问题逐渐显现。为此&#xff0c;Spring Boot 应运而生。 Spring Boo…
阅读更多...
基于CNN卷积神经网络和GEI步态能量提取的视频人物步态识别算法matlab仿真

基于CNN卷积神经网络和GEI步态能量提取的视频人物步态识别算法matlab仿真

目录 1.算法运行效果图预览 2.算法运行软件版本 3.部分核心程序 4.算法理论概述 4.1 GEI步态能量提取 4.2 CNN卷积神经网络原理 5.算法完整程序工程 1.算法运行效果图预览 (完整程序运行后无水印) 2.算法运行软件版本 matlab2024b/matlab2022a 3.部分核心程序 &…
阅读更多...
创建型模式：建造者模式

创建型模式：建造者模式

什么是建造者模式 建造者模式&#xff08;Builder Pattern&#xff09;是一种创建型设计模式&#xff0c;它将一个复杂对象的构建过程与其表示分离&#xff0c;使得同样的构建过程可以创建不同的表示。简单来说&#xff0c;建造者模式允许您一步一步创建复杂对象&#xff0c;而…
阅读更多...
Linux `init 5` 相关命令的完整使用指南

Linux `init 5` 相关命令的完整使用指南

Linux init 5 相关命令的完整使用指南—目录 一、init 系统简介二、init 5 的含义与作用三、不同 Init 系统下的 init 5 行为1. SysVinit&#xff08;如 CentOS 6、Debian 7&#xff09;2. systemd&#xff08;如 CentOS 7、Ubuntu 16.04&#xff09;3. Upstart&#xff08;如 …
阅读更多...
RabbitMQ常见面试题回答重点

RabbitMQ常见面试题回答重点

文章目录 什么是消息队列&#xff1f;为什么需要消息队列消息队列的模型消息队列常见名词如何保证消息不丢失&#xff1f;&#xff08;可靠性&#xff09;如何保证消息不重复/业务幂等性如何保证消息有序性如何处理消息堆积消息队列设计为推送还是拉取 / 推拉模式优点无法路由的…
阅读更多...
欣佰特携数十款机器人相关前沿产品，亮相第二届人形机器人和具身智能行业盛会

欣佰特携数十款机器人相关前沿产品，亮相第二届人形机器人和具身智能行业盛会

2025年4月15日至16日&#xff0c;备受关注的第二届中国人形机器人与具身智能产业大会已在北京成功举行。作为国内前沿科技及产品服务领域的重要参与者&#xff0c;欣佰特科技携众多前沿产品精彩亮相&#xff0c;全方位展示了其在人形机器人与具身智能领域的创新产品。 在本次大…
阅读更多...
Docker安装 (centos)

Docker安装 (centos)

1.安装依赖包&#xff1a; sudo yum install -y yum-utils device-mapper-persistent-data lvm2 2.删除已有的 Docker 仓库文件&#xff08;如果有&#xff09;&#xff1a; sudo rm -f /etc/yum.repos.d/docker-ce.repo 3.添加阿里云的 Docker 仓库&#xff1a; sudo yum…
阅读更多...
Vue接口平台学习十——接口用例页面2

Vue接口平台学习十——接口用例页面2

效果图及简单说明 左边选择用例&#xff0c;右侧就显示该用例的详细信息。 使用el-collapse折叠组件&#xff0c;将请求到的用例详情数据展示到页面中。 所有数据内容&#xff0c;绑定到caseData中 // 页面绑定的用例编辑数据 const caseData reactive({title: "",…
阅读更多...
服务器数据迁移指南

服务器数据迁移指南

服务器数据迁移是将数据从一台服务器转移到另一台服务器的过程&#xff0c;可能是为了硬件升级、云迁移、数据中心搬迁或服务整合。 以下是数据迁移的关键步骤和注意事项&#xff1a; 迁移前准备 制定迁移计划 确定迁移范围(全量/增量) 评估数据量和网络带宽 制定时间表和回…
阅读更多...
25.解决中医知识问答删除历史对话功能后端处理请求时抛出异常

25.解决中医知识问答删除历史对话功能后端处理请求时抛出异常

ChatTest.vue:176 DELETE http://localhost:8080/api/chat/conversations/20 500 (Internal Server Error) deleteConversation ChatTest.vue:176 onClick ChatTest.vue:22 ChatTest.vue:185 删除失败 AxiosError {message: Request failed with status code 500, name: Axio…
阅读更多...
记录seatunnel排查重复数据的案例分析

记录seatunnel排查重复数据的案例分析

文章目录 背景分析检查现象检查B集群是否有异常&#xff0c;导致重复消费的分析同步任务 修复问题发现flink job 一直报异常修复问题 背景 使用seatunnel 同步数据从A 集群kafka 同步到B集群kafka,现象是发现两边数据不一致&#xff0c;每天10w级别会多几十条数据 分析 检查…
阅读更多...
最新文章

Copyright @ 2022~2023