docker composeyaml文件，什么是swap-space，内存不足硬盘来凑，--ipc=host，yaml文件、环境变量、容器报警健康检查

news2025/3/16 5:57:36

--swap-space 参数明确针对的是系统内存（RAM），与显存（GPU Memory）无关。以下是关键区分：

内存（RAM） vs 显存（GPU Memory）

类型内存（RAM）显存（GPU Memory）
物理位置主板上的内存条（CPU 直接访问）显卡上的专用内存（GPU 直接访问）
用途存储 CPU 运行时的程序和数据存储 GPU 计算时的模型权重、输入数据等
不足后果系统卡顿、崩溃，触发 OOM（内存不足）GPU 计算中断，报 CUDA Out Of Memory 错误
扩展方式增加内存条 或 配置交换空间（Swap）减小批次大小（batch size）、优化模型占用

为什么 --swap-space 作用于内存而非显存？

  1. 显存无法通过 Swap 扩展
    显存是 GPU 硬件直接管理的资源，无法通过硬盘交换空间扩展。若显存不足，必须通过优化模型、减少批次大小或使用更高显存的 GPU 来解决。

  2. GPU 任务依赖内存
    GPU 计算任务（如深度学习训练）需要 CPU 和内存的协同工作：

    • 数据预处理：CPU 从磁盘加载数据到内存，再传输到 GPU 显存。
    • 计算流水线：内存负责管理任务队列、中间结果缓存等。
      若内存不足，即使显存足够，任务也会因 CPU 端资源不足而崩溃。此时交换空间（Swap）可为内存提供临时扩展。

典型场景示例

假设你使用 2 块 GPU 训练模型：

  • 显存占用：每块 GPU 显存使用 10 GiB（共 20 GiB）。
  • 内存占用：数据预处理、任务管理等消耗 30 GiB RAM。

若物理内存仅 32 GiB，剩余 2 GiB 可能不足以应对波动，此时：

  • 未配置 Swap：系统直接 OOM，任务崩溃。
  • 配置 --swap-space 8：系统为每个 GPU 关联的任务分配 8 GiB 交换空间（共 16 GiB），内存不足时部分数据暂存到硬盘，任务可继续运行（但性能下降）。

如何确定是内存还是显存不足？

  1. 显存不足的症状

    • 报错信息含 CUDA Out Of Memory。
    • 使用 nvidia-smi 监控显存占用（通常接近 100%）。

  2. 内存不足的症状

    • 系统卡顿、进程被终止。
    • 使用 free -h 或 htop 查看内存和 Swap 使用率。

总结

  • --swap-space 是内存（RAM）的应急扩展机制，与显存无关。
  • 显存不足必须通过优化模型或硬件升级解决，Swap 对此无能为力。
  • 合理配置 Swap 可避免 CPU/内存端的任务崩溃，但会牺牲性能。

在Docker命令中，--ipc=host参数用于控制容器的进程间通信（IPC）命名空间配置。具体作用如下：

--ipc=host 的含义

  1. 共享宿主机的IPC命名空间
    使用此选项后，容器将直接使用宿主机的IPC资源（如共享内存、信号量、消息队列等），而不是拥有独立的IPC命名空间。

  2. 典型用途

    • 当容器内的应用需要与宿主机或其他容器高效共享内存时（例如某些数据库、科学计算或高性能计算场景）。
    • 例如，运行PostgreSQL、Redis或使用共享内存加速的应用程序时，可能需要此配置。

为什么需要这个参数？

  • 默认行为：Docker容器默认有自己独立的IPC命名空间，与宿主机和其他容器隔离。
  • 性能与兼容性：共享IPC命名空间可以绕过隔离带来的性能损耗，但也可能引入安全风险（容器可能干扰宿主机的IPC资源）。

示例场景

假设你在容器中运行一个需要与宿主机共享内存的进程：

docker run -it --ipc=host my_app_image

此时，容器内的进程可以直接访问宿主机的共享内存段。

其他可选值

  • --ipc=container:<容器名/ID>：加入另一个容器的IPC命名空间。
  • 不指定--ipc：默认创建独立的IPC命名空间。

安全提示

  • 慎用--ipc=host：共享宿主机的IPC可能破坏容器隔离性，存在安全风险。仅在必要时使用。
  • 替代方案：优先考虑使用--ipc=shareable（允许其他容器加入）或命名卷共享数据。

希望这个解释能帮到你！如果有更多问题，欢迎继续提问 😊

以下是针对您问题的分点解答：

一、version: '3.8' 的含义

这是 Docker Compose 文件的格式版本标识，具体作用如下：

  1. 语法规则定义
    不同版本的 Compose 文件支持不同的配置语法和功能。3.8 表示使用 Compose 文件格式的第 3.8 版规范。

  2. 兼容性要求

    • 需要 Docker Engine 18.06.0+ 支持
    • 需要 Docker Compose 1.25.0+ 版本解析

  3. 关键特性支持
    该版本主要支持以下特性：

    • 服务扩展配置 (deploy.reservations)
    • 更灵活的资源限制 (resources.limits)
    • Secret/Config 的高级管理
    • 多阶段构建优化

  4. 实际意义
    在您的配置中，3.8 版本确保了以下配置项有效：

    shm_size: 100gb        # 共享内存控制
ulimits:               # 资源限制
  memlock: -1
security_opt:          # 安全策略
  - "seccomp=unconfined"

二、容器停止后的重启机制

在您的配置中，通过 restart: unless-stopped 设置了重启策略，具体行为如下：

  1. 自动重启触发条件

    场景是否重启示例
    容器异常退出 (非0状态码)✅ 是程序崩溃、OOM 内存溢出
    宿主机重启✅ 是服务器断电后恢复
    手动停止容器❌ 否docker stop embed-rerank
    显式删除容器❌ 否docker rm embed-rerank

  2. 策略对比

    策略描述您的配置采用
    no永不重启❌
    on-failure非0退出时重启❌
    always总是重启（含手动停止）❌
    unless-stopped自动重启，除非显式停止✅

  3. 验证方法

    # 模拟异常退出
docker exec embed-rerank kill 1

# 观察重启状态（约10秒后）
docker ps -a | grep embed-rerank

# 手动停止测试
docker stop embed-rerank
docker start embed-rerank  # 此时需手动启动

三、生产环境建议

  1. 版本控制
    保持 version: '3.8' 以获得最新功能支持，但需确保 Docker 环境符合版本要求：

    docker --version        # 需 ≥ 18.06.0
docker-compose --version # 需 ≥ 1.25.0

  2. 重启策略优化
    如果希望实现更精准的控制，可改用：

    restart: on-failure:5   # 最多重启5次

  3. 日志监控
    建议添加日志管理和监控：

    logging:
  driver: "json-file"
  options:
    max-size: "100m"
    max-file: "3"

通过以上配置，您的服务将在异常情况下保持高可用性，同时避免因手动维护导致的意外重启。

以下是 Docker Compose 配置的逐行专业解析，结合技术原理与最佳实践说明：

一、基础框架

version: '3.8'  # Compose文件规范版本，需Docker 18.06+支持
services:        # 定义容器服务的起点
  embed-rerank:  # 服务标识符（业务语义化命名）

二、核心配置解析

1. 镜像定义
image: inference-llm-deepseekr1_opt:v2
  • 作用：指定基础镜像（含预装依赖）
  • 要点：
    • inference-llm-deepseekr1_opt：镜像名称（通常包含框架优化如TensorRT/ONNX Runtime）
    • v2：版本标签（确保模型兼容性）
2. 容器标识
container_name: embed-rerank
  • 作用：固定容器名称（避免随机命名）
  • 优势：
    • 便于日志查询：docker logs embed-rerank
    • 简化运维操作：docker exec -it embed-rerank bash
3. 生命周期管理
restart: unless-stopped
  • 策略层级：
    策略自启触发条件生产建议
    no永不重启测试环境
    always无条件重启慎用（可能导致僵尸服务）
    on-failure异常退出时重启通用方案
    unless-stopped非主动停止时重启当前配置（推荐）
4. 网络端口
ports: 
  - "18005:8000"  # 宿主机端口:容器端口
  • 技术细节：
    • 容器内服务监听 8000 端口（需与vLLM参数匹配）
    • 外部通过宿主机 18005 访问（需防火墙放行）
  • 风险提示：直接暴露端口需配合API密钥使用

三、硬件加速配置

1. 设备直通
devices:
  - "/dev/mxcd:/dev/mxcd"              # 机器学习加速卡
  - "/dev/dri/card3:/dev/dri/card3"    # GPU渲染设备
  - "/dev/dri/renderD130:/dev/dri/renderD130"
  - "/dev/dri/card4:/dev/dri/card4" 
  - "/dev/dri/renderD131:/dev/dri/renderD131"
  - "/dev/mem:/dev/mem"                # 物理内存访问
  • 作用：透传硬件加速设备
  • 设备类型：
    • /dev/dri/*：Intel/NVIDIA 显卡渲染节点
    • /dev/mxcd：专用AI加速芯片（如寒武纪MLU）
    • /dev/mem：直接内存访问（需谨慎）
2. 用户组权限
group_add: 
  - video  # 加入video用户组
  • 原理：Linux设备访问控制
  • 必要性：访问 /dev/dri 等设备需video组权限

四、安全配置

1. 安全策略解除
security_opt:
  - "seccomp=unconfined"   # 禁用系统调用过滤
  - "apparmor=unconfined"  # 禁用访问控制
  • 使用场景：需要高性能计算时
  • 风险提示：降低容器隔离性（仅限可信环境使用）
2. 内存锁定
ulimits:
  memlock: -1  # 解除内存锁定限制
  • 技术原理：防止内存交换（swap）
  • 业务价值：保障大模型推理的稳定性

五、存储配置

1. 共享内存
shm_size: 100gb  # /dev/shm容量
  • 作用：进程间高速通信
  • 最佳实践：大模型服务建议 ≥ 模型参数量的30%
2. 卷挂载
volumes:
  - "/usr/local/:/usr/local/"             # 共享宿主系统库
  - "/home/ictrek/models:/root/models"    # 模型数据映射
  • 路径解析：
    • /usr/local：透传CUDA等加速库（避免容器内重复安装）
    • ~/models：模型文件热更新（无需重建镜像）

六、vLLM服务参数精析

启动命令全景
vllm serve /root/models/bge-reranker-v2-m3 \
  --tensor-parallel-size 2 \          # 张量并行
  --trust-remote-code \               # 加载自定义代码
  --dtype float16 \                   # 计算精度
  --served-model-name embed-rerank \  # API端点标识
  --host 0.0.0.0 \                    # 监听地址
  --port 8000 \                       # 服务端口
  --gpu-memory-utilization 0.1 \      # GPU显存管理
  --swap-space 16 \                   # 交换空间
  --api-key ltkj-123 \                # 认证密钥
  --enable-prefix-caching             # 前缀缓存
关键参数详解

  1. 计算加速类

    --tensor-parallel-size 2    # 张量并行度（TP=2）
--dtype float16             # 半精度推理（速度↑ 内存↓）
    • 性能影响：相比float32，float16可提升1.5-2倍推理速度
    • 硬件要求：需GPU支持FP16（如Volta架构+）

  2. 资源管理类

    --gpu-memory-utilization 0.1  # 显存利用率阈值（动态分配）
--swap-space 16               # 交换空间（单位：GB）
    • 内存策略：
      • 超过10%显存利用率时触发卸载
      • 16GB交换空间用于存放卸载参数

  3. 安全控制类

    --api-key ltkj-123         # API访问密钥
--trust-remote-code        # 允许加载自定义HuggingFace代码
    • 安全警示：
      • 密钥需定期轮换（建议集成Vault等密钥管理）
      • trust-remote-code 需审核模型来源（有代码执行风险）

  4. 性能优化类

    --enable-prefix-caching    # 前缀缓存（加速生成任务）
    • 工作原理：缓存对话/生成长文本的公共前缀
    • 性能收益：重复前缀场景可提升30%+吞吐量

七、生产环境验证清单

  1. 硬件检查

    ls -l /dev/dri/   # 确认渲染设备存在
nvidia-smi        # 检查GPU状态

  2. 服务健康检查

    curl http://localhost:18005/health
# 预期输出：{"status":"OK"}

  3. API功能验证

    curl -H "Authorization: Bearer ltkj-123" \
  http://localhost:18005/v1/models
# 应返回模型元信息

  4. 性能监控建议

    watch -n 1 "docker stats embed-rerank"  # 实时资源监控
nvtop                                  # GPU利用率观测

通过以上配置，可实现高性能、可观测的大模型推理服务部署。

环境变量可以理解为操作系统为程序运行设定的全局快捷方式，它通过预设参数和路径让系统更智能地找到资源。用生活中的场景类比，就像快递员根据地址簿快速找到收件人地址一样，环境变量帮助程序快速定位所需文件或配置。以下是通俗理解的核心要点：

一、环境变量的核心作用

  1. 路径导航
    当你在命令行输入notepad时，系统会自动在PATH环境变量中记录的路径里查找记事本程序，无需手动输入完整路径（如C:\Windows\system32\notepad.exe）。这类似于给常用工具设置“快捷方式”。

  2. 跨程序共享配置
    例如，JAVA_HOME环境变量记录了Java安装路径，其他软件（如Maven）可以直接读取该路径，避免每个软件都单独配置Java位置。

  3. 动态适应环境
    同一台电脑可能有不同用户或系统版本（如Windows双系统），通过环境变量可以统一管理临时文件路径（如TEMP）、用户目录（如HOME），确保程序在不同环境下正常运行。

二、常见环境变量示例

变量名作用
PATH系统搜索程序的默认路径，如C:\Windows\system32和/usr/bin。
TEMP临时文件夹路径，存放程序运行时产生的临时文件。
JAVA_HOME指定Java安装路径，供开发工具调用。
HOME用户的主目录（如Windows的C:\Users\用户名）。

三、通俗比喻

  1. “地址簿”
    环境变量像一本地址簿，系统根据名称（如PATH）直接查找对应的路径，省去手动输入完整地址的麻烦。

  2. “全局设置”
    类似手机的系统语言设置，所有App都会自动适配语言，环境变量让所有程序共享同一套配置。

  3. “隐形管家”
    用户无需感知环境变量存在，但它们默默支撑着程序运行（如浏览器自动读取网络代理配置）。

四、实际应用场景

  • 快速打开软件：将QQ安装路径加入PATH后，任意位置输入QQ即可启动程序。
  • 多版本兼容：通过切换JAVA_HOME的值，同一台电脑可运行不同版本的Java程序。
  • 临时文件管理：%TEMP%环境变量指向的文件夹自动清理，避免手动维护。

通过以上解释，环境变量的核心价值在于简化操作、统一配置、提升效率。理解它后，你会更清楚为何安装软件时要“配置环境变量”，以及系统如何实现“智能查找”。

容器报警：

以下是关于Docker健康检查配置的逐层解析，结合技术规范和实际运行机制说明：

一、检查对象与流程原理

  1. 检查对象
    该配置针对的是容器内运行的应用程序。通过向容器内部署的应用发送HTTP请求（如http://localhost:8080/health），检测服务是否正常响应。若应用崩溃或无法处理请求，则判定为不健康。

  2. 触发条件与周期

    • interval: 30秒：从第一次检查开始，每30秒触发一次健康检测。
    • 连续3次失败判定不健康：若连续3次检测均失败（如HTTP返回非2xx/3xx状态码），Docker会将容器标记为unhealthy。

二、检测执行细节

  1. 核心参数解释（以配置为例）
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
  interval: 30s 
  retries: 3
  • test：检测指令，通过curl -f强制返回非0状态码（若HTTP响应码≥400则失败）。
  • interval：两次检测的间隔时间（需配合retries计算总超时时间）。
  • retries：允许的连续失败次数，超过后标记为不健康。
  1. 完整检测逻辑时间轴
  • 首次检测：容器启动后立即执行（默认无延迟）
  • 检测流程示例：
    • T=0秒：第一次检测失败 → 计数器+1
    • T=30秒：第二次检测失败 → 计数器+1
    • T=60秒：第三次检测失败 → 标记为unhealthy
  • 总判定时间：若连续失败，需30s×(3-1)=60秒触发状态变更。

三、故障报警实现方案

  1. Docker原生机制
  • 状态查询：通过docker inspect --format='{{.State.Health.Status}}' <容器名>获取状态。
  • 日志记录：检测失败日志会写入容器事件（docker events可查看）。
  1. 报警集成方案
  • 方案1：脚本轮询
    # 监控脚本示例 
if [ "$(docker inspect --format='{{.State.Health.Status}}' myapp)" = "unhealthy" ]; then 
  send_alert "容器myapp健康检查失败！"
fi
  • 方案2：Prometheus+Alertmanager
    通过cAdvisor采集容器健康状态指标，配置报警规则：
    # Prometheus规则示例 
- alert: ContainerUnhealthy 
  expr: container_health_status{status="unhealthy"} == 1 
  for: 1m 
  annotations:
    summary: "容器{{ $labels.name }}健康检查失败"

四、扩展建议

  1. 增强检测可靠性

    • 增加timeout: 5s参数，避免因网络延迟误判
    • 结合start_period: 60s，允许容器启动初期不触发检测。

  2. 多维度监控

    • 同时配置liveness（存活检查）和readiness（就绪检查）探针
    • 示例（Kubernetes风格）：
      healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
  interval: 30s 
  timeout: 5s 
  retries: 3 
  start_period: 60s

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

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

相关文章

Uniapp 开发 App 端上架用户隐私协议实现指南

Uniapp 开发 App 端上架用户隐私协议实现指南

文章目录 引言一、为什么需要用户隐私协议&#xff1f;二、Uniapp 中实现用户隐私协议的步骤2.1 编写隐私协议内容2.2 在 Uniapp 中集成隐私协议2.3 DCloud数据采集说明2.4 配置方式3.1 Apple App Store3.2 Google Play Store 四、常见问题与解决方案4.1 隐私协议内容不完整4.2…
阅读更多...
LeetCode 环形链表II：为什么双指针第二次会在环的入口相遇？

LeetCode 环形链表II：为什么双指针第二次会在环的入口相遇？

快慢指针 为什么相遇后让快指针回到起点&#xff0c;再让快指针和慢指针都一步一步地走&#xff0c;它们就会在环的入口相遇&#xff1f; 复杂度 时间复杂度: O(n) 空间复杂度: O(1) public ListNode detectCycle(ListNode head) {ListNode slow head, fast head;ListNode …
阅读更多...
如何处理PHP中的编码问题

如何处理PHP中的编码问题

如何处理PHP中的编码问题 在PHP开发过程中&#xff0c;编码问题是一个常见且棘手的问题。无论是处理用户输入、数据库交互&#xff0c;还是与外部API通信&#xff0c;编码问题都可能导致数据乱码、解析错误甚至安全漏洞。本文将深入探讨PHP中的编码问题&#xff0c;并提供一些…
阅读更多...
【动手学强化学习】part8-PPO(Proximal Policy Optimization)近端策略优化算法

【动手学强化学习】part8-PPO(Proximal Policy Optimization)近端策略优化算法

阐述、总结【动手学强化学习】章节内容的学习情况&#xff0c;复现并理解代码。 文章目录 一、算法背景1.1 算法目标1.2 存在问题1.3 解决方法 二、PPO-截断算法2.1 必要说明2.2 伪代码算法流程简述 2.3 算法代码2.4 运行结果2.5 算法流程说明 三、疑问四、总结 一、算法背景 …
阅读更多...
游戏引擎学习第159天

游戏引擎学习第159天

回顾与今天的计划 我们在完成一款游戏的制作。这个游戏没有使用任何引擎或新库&#xff0c;而是从零开始编写的完整游戏代码库&#xff0c;您可以自行编译它&#xff0c;并且它是一个完整的游戏。更特别的是&#xff0c;这个游戏甚至没有使用显卡&#xff0c;所有的渲染工作都…
阅读更多...
内网攻防——红日靶场（一）

内网攻防——红日靶场（一）

在学习内网的过程中有着诸多不了解的内容。希望能借下面的靶场来步入内网的大门。 一、准备阶段 首先准备好我们的虚拟机 之前有学过关于&#xff1a;工作组、域、DC的概念。 了解一下此时的网络拓扑图 1.设置网络VMnet1和Vmnet8 将VMnet1作为内网&#xff0c;VMnet8作为外…
阅读更多...
协议-LoRa-Lorawan

协议-LoRa-Lorawan

是什么？ LoRa是低功耗广域网通信技术中的一种，是Semtech公司专有的一种基于扩频技术的超远距离无线传输技术。LoRaWAN是为LoRa远距离通信网络设计的一套通讯协议和系统架构。它是一种媒体访问控制（MAC）层协议。LoRa = PHY Layer LoRaWAN = MAC Layer功耗最低，传输最远 ![ …
阅读更多...
redis主从搭建

redis主从搭建

1. 哨兵 1.1 ⼈⼯恢复主节点故障 Redis 的主从复制模式下&#xff0c;⼀旦主节点由于故障不能提供服务&#xff0c;需要⼈⼯进⾏主从切换&#xff0c;同时⼤量 的客⼾端需要被通知切换到新的主节点上&#xff0c;对于上了⼀定规模的应⽤来说&#xff0c;这种⽅案是⽆法接受的&…
阅读更多...
Linux中Gdb调试工具常用指令大全

Linux中Gdb调试工具常用指令大全

1.gdb的安装 如果你是root用户直接用指令 &#xff1a;yum install gdb &#xff1b;如果你是普通用户用指令&#xff1a;sudo yum install gdb&#xff1b; 2.gdb调试前可以对你的makefile文件进行编写&#xff1a; 下面展示为11.c文件编写的makefile文件&#xff1a; code…
阅读更多...
操作系统-八股

操作系统-八股

进程基础&#xff1a; 进程定义&#xff1a;运行中的程序&#xff0c;有独立的内存空间和地址&#xff0c;是系统进行资源调度和分配的基本单位。 并发&#xff0c;并行 并发就是单核上面轮询&#xff0c;并行就是同时执行&#xff08;多核&#xff09;&#xff1b; 进程上下…
阅读更多...
ICLR2025 | SLMRec: 重新思考大语言模型在推荐系统中的价值

ICLR2025 | SLMRec: 重新思考大语言模型在推荐系统中的价值

note 问题背景&#xff1a;序列推荐&#xff08;SR&#xff09;任务旨在预测用户可能的下一个交互项目。近年来&#xff0c;大型语言模型&#xff08;LLMs&#xff09;在SR系统中表现出色&#xff0c;但它们巨大的规模使得在实际平台中应用变得低效和不切实际。 研究动机&…
阅读更多...
71.HarmonyOS NEXT PicturePreviewImage组件深度剖析：从架构设计到核心代码实现

71.HarmonyOS NEXT PicturePreviewImage组件深度剖析：从架构设计到核心代码实现

温馨提示&#xff1a;本篇博客的详细代码已发布到 git : https://gitcode.com/nutpi/HarmonyosNext 可以下载运行哦&#xff01; HarmonyOS NEXT PicturePreviewImage组件深度剖析&#xff1a;从架构设计到核心代码实现 (一) 文章目录 HarmonyOS NEXT PicturePreviewImage组件深…
阅读更多...
简单实现京东登录页面

简单实现京东登录页面

Entry Component struct Index {State message: string ;build() { Column(){//顶部区域Row(){Image($r(app.media.jd_cancel)).width(20).height(20)Text(帮助)}.width(100%).justifyContent(FlexAlign.SpaceBetween)//logo图标Image($r(app.media.jd_logo)).width(250).heig…
阅读更多...
9.贪心算法

9.贪心算法

简单贪心 1.P10452 货仓选址 - 洛谷 #include<iostream> #include<algorithm> using namespace std;typedef long long LL; const int N 1e510; LL a[N]; LL n;int main() {cin>>n;for(int i 1;i < n;i)cin>>a[i];sort(a1,a1n);//排序 LL sum 0…
阅读更多...
大模型训练全流程深度解析

大模型训练全流程深度解析

前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不住分享一下给大家。点击跳转到网站。https://www.captainbed.cn/north 文章目录 1. 大模型训练概览1.1 训练流程总览1.2 关键技术指标 2. 数据准备2.1 数据收集与清洗2.2 数据…
阅读更多...
每日一题---单词搜索（深搜）

每日一题---单词搜索（深搜）

单词搜索 给出一个二维字符数组和一个单词&#xff0c;判断单词是否在数组中出现&#xff0c; 单词由相邻单元格的字母连接而成&#xff0c;相邻单元指的是上下左右相邻。同一单元格的字母不能多次使用。 数据范围&#xff1a; 0 < 行长度 < 100 0 < 列长度 <…
阅读更多...
插入排序c++

插入排序c++

插入排序的时间复杂度为O&#xff08;N^2&#xff09;&#xff0c;和冒泡排序的时间复杂度相同&#xff0c;但是在某些情况下插入排序会更优。 插入排序的原理是&#xff1a;第1次在0~0范围内排序&#xff0c;第2次在0~1范围内排序&#xff0c;第3次在0~2范围内排序……相当于…
阅读更多...
Swagger 从 .NET 9 中删除：有哪些替代方案

Swagger 从 .NET 9 中删除：有哪些替代方案

微软已经放弃了对 .NET 9 中 Swagger UI 包 Swashbuckle 的支持。他们声称该项目“不再由社区所有者积极维护”并且“问题尚未得到解决”。 这意味着当您使用 .NET 9 模板创建 Web API 时&#xff0c;您将不再拥有 UI 来测试您的 API 端点。 我们将调查是否可以在 .NET 9 中使用…
阅读更多...
嵌入式八股ARM篇

嵌入式八股ARM篇

前言 ARM篇主要介绍一下寄存器和中断机制,至于汇编这一块…还请大家感兴趣自行学习 1.寄存器 R0 - R3 R4 - R11 寄存器 R0 - R3一般用作函数传参 R4 - R11用来保存程序运算的中间结果或函数的局部变量 在函数调用过程中 注意在发生异常的时候 cortex-M0架构会自动将R0-R3压入…
阅读更多...
使用DeepSeek和墨刀AI，写PRD文档、画原型图的思路、过程及方法

使用DeepSeek和墨刀AI，写PRD文档、画原型图的思路、过程及方法

使用DeepSeek和墨刀AI&#xff0c;写PRD文档、画原型图的思路、过程及方法 现在PRD文档要如何写更高效、更清晰、更完整&#xff1f; 还是按以前的思路写PRD&#xff0c;就还是以前的样子。 现在AI这么强大&#xff0c;产品经理如何使用DeepSeek写PRD文档&#xff0c;产品经…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023