Java 21虚拟线程内存泄漏检测实战（仅限少数人掌握的诊断技巧）

原创 于 2025-12-04 14:23:09 发布 · 787 阅读 · 22 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测

第一章：Java 21虚拟线程内存泄漏检测的认知革命

Java 21 引入的虚拟线程（Virtual Threads）标志着并发编程的一次重大跃迁，极大提升了应用的吞吐能力。然而，伴随其轻量级特性的普及，传统堆内存分析手段在识别虚拟线程引发的资源滞留问题时逐渐失效，催生了对内存泄漏检测的新认知。

虚拟线程与平台线程的本质差异

  • 虚拟线程由 JVM 调度，生命周期短暂且数量庞大，不同于依赖操作系统调度的平台线程
  • 每个虚拟线程栈空间动态分配，难以通过传统线程转储（thread dump）追踪长期持有的引用
  • 大量空闲虚拟线程若未被及时回收，可能间接导致 GC 压力上升和堆内存膨胀

检测虚拟线程内存异常的关键策略

策略工具/方法适用场景
结构化监控JFR（Java Flight Recorder）事件类型 jdk.VirtualThreadStart跟踪虚拟线程创建频率与存活时间
堆外引用分析Eclipse MAT 结合 OQL 查询定位未释放的 ThreadLocal 或共享上下文引用

使用 JFR 捕获虚拟线程行为示例


// 启用飞行记录器以捕获虚拟线程事件
// JVM 参数配置：
// -XX:+UnlockCommercialFeatures \
// -XX:+FlightRecorder \
// -XX:StartFlightRecording=duration=60s,filename=vt-leak.jfr

public class VirtualThreadExample {
    public static void main(String[] args) throws InterruptedException {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 10_000; i++) {
                executor.submit(() -> {
                    var localData = new byte[1024]; // 模拟局部对象
                    Thread.sleep(1000);
                    return null;
                });
            }
            Thread.sleep(5000); // 等待观察行为
        }
    }
}

上述代码在高并发提交任务后若未及时关闭执行器，可能导致大量虚拟线程状态驻留于 JVM 内部结构中，需结合 JFR 分析其生命周期分布。

graph TD A[应用启动] --> B{是否启用JFR?} B -->|是| C[记录VirtualThread事件] B -->|否| D[无法追溯线程行为] C --> E[导出JFR文件] E --> F[使用JDK Mission Control分析] F --> G[识别异常生命周期模式]

第二章：虚拟线程内存泄漏的底层机制与识别

2.1 虚拟线程与平台线程的内存模型差异

虚拟线程和平台线程在内存模型上的根本差异在于栈空间管理方式。平台线程依赖操作系统级的固定大小栈（通常为1MB），而虚拟线程采用轻量化的**受限栈**，其栈帧存储在堆上，通过链表动态扩展。
内存占用对比
  • 平台线程：每个线程独占大块连续栈内存，创建上千线程极易导致内存溢出
  • 虚拟线程：栈数据以对象形式存于堆中，仅在调度时加载到载体线程，显著降低内存压力

VirtualThread.startVirtualThread(() -> {
    System.out.println("运行在虚拟线程");
});
上述代码启动一个虚拟线程，其执行上下文由JVM在堆中分配，不依赖内核线程栈。每次调度时，JVM将该上下文挂载到某个平台线程（载体线程）上执行，实现“多对一”的栈映射机制，极大提升并发密度。

2.2 虚拟线程生命周期管理中的隐患点剖析

生命周期状态跃迁的隐式中断
虚拟线程在调度过程中可能因平台线程抢占或阻塞操作突然挂起，导致状态跃迁不完整。例如，在从“运行”到“等待”的转换中缺乏原子性保障，易引发状态不一致。 

VirtualThread vt = (VirtualThread) Thread.startVirtualThread(() -> {
    synchronized (lock) {
        while (!condition) {
            LockSupport.park(); // 可能被外部中断误触发
        }
    }
});
上述代码中，LockSupport.park() 若未配合中断状态判断，可能导致虚拟线程无法正确恢复，形成悬挂实例。
资源泄漏与未捕获的异常传播
  • 虚拟线程异常退出时未关闭关联的文件句柄或网络连接
  • 异常未被主线程捕获，导致监控系统遗漏故障上下文

2.3 常见泄漏场景：未正确关闭资源与阻塞操作

在高并发系统中，资源管理不当极易引发内存或句柄泄漏。典型场景之一是未正确关闭 I/O 资源，如文件描述符、网络连接或数据库会话。
资源未关闭示例
func handleConn(conn net.Conn) {
    // 忘记 defer conn.Close() 导致连接泄漏
    data, _ := ioutil.ReadAll(conn)
    process(data)
}
上述代码未显式关闭连接，当并发量上升时，文件描述符将被迅速耗尽。
阻塞操作导致的泄漏
  • 协程因 channel 操作无缓冲且无超时而永久阻塞
  • 锁未释放导致后续请求堆积
  • 定时任务未取消，在对象销毁后仍运行
正确做法是在资源获取后立即使用 defer 确保释放，同时为阻塞操作设置上下文超时。

2.4 利用JVM指标识别异常增长的虚拟线程数

随着虚拟线程在Java应用中的广泛使用，监控其数量变化成为保障系统稳定的关键。JVM通过Metrics接口暴露了虚拟线程的运行时数据，开发者可借助这些指标及时发现线程激增问题。
JVM暴露的关键指标
JVM提供的`ThreadMXBean`接口新增了对虚拟线程的支持，可通过以下方式获取实时数据：
  • getPeakVirtualThreadCount()：返回峰值虚拟线程数
  • getCurrentVirtualThreadCount()：返回当前活跃虚拟线程数
  • getTotalStartedVirtualThreadCount()：返回累计启动的虚拟线程总数
监控代码示例
ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
long currentVThreads = threadBean.getCurrentVirtualThreadCount();
if (currentVThreads > THRESHOLD) {
    logger.warn("Virtual thread count exceeds threshold: {}", currentVThreads);
}
上述代码定期检查当前虚拟线程数量，当超过预设阈值时触发告警。结合Prometheus等监控系统，可实现可视化追踪与自动预警。

2.5 通过Thread Dump洞察虚拟线程堆积现象

虚拟线程虽轻量，但在高并发场景下仍可能因阻塞或调度延迟导致堆积。通过生成和分析 Thread Dump，可直观识别此类问题。
获取Thread Dump
在应用响应变慢时，使用 jcmd <pid> Thread.dump 或 kill -3 <pid> 生成线程快照。
识别虚拟线程堆积
查看输出中大量处于 RUNNABLE 状态的虚拟线程，尤其是堆叠在特定方法上的调用链： 

"VirtualThread[#23]" #23 virtual running
    at com.example.service.DataService.process(DataService.java:45)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
该代码段显示虚拟线程在 process 方法中持续运行，若数百个线程均停留于此，表明处理逻辑存在瓶颈。
常见堆积原因
  • 同步阻塞：虚拟线程调用外部同步API
  • CPU密集任务：未拆分计算负载
  • 资源竞争：数据库连接池耗尽

第三章：诊断工具链的实战配置与应用

3.1 使用JMC（Java Mission Control）捕获虚拟线程行为

Java Mission Control（JMC）是分析JVM运行时行为的强有力工具，尤其适用于观察虚拟线程（Virtual Threads）的生命周期与调度模式。启用虚拟线程监控需在启动应用时添加特定参数。 
java -XX:+EnablePreview -XX:+UnlockCommercialFeatures \
     -XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=virtual-threads.jfr \
     MyApp
上述命令启用Java Flight Recorder（JFR），并记录60秒内的运行数据。其中 `-XX:+FlightRecorder` 激活记录功能，`StartFlightRecording` 定义录制时长与输出文件。
关键事件类型
JFR会捕获以下与虚拟线程相关的事件：
  • jdk.VirtualThreadStart：虚拟线程启动时刻
  • jdk.VirtualThreadEnd：虚拟线程结束时刻
  • jdk.VirtualThreadPinned：线程被固定在载体线程上，可能影响并发性能
通过JMC图形界面打开生成的JFR文件，可直观查看虚拟线程的创建频率、执行时间分布及阻塞情况，帮助识别潜在的载体线程竞争问题。

3.2 JFR（Java Flight Recorder）事件定制与分析技巧

JFR 允许开发者定义自定义事件，以捕获应用特有的性能数据。通过继承 jdk.jfr.Event 类并标注关键字段，即可实现精细化监控。
自定义事件实现

@Label("Cache Access Event")
public class CacheAccessEvent extends Event {
    @Label("Cache Name") String cacheName;
    @Label("Hit Count") int hitCount;
    @Label("Operation Time") long operationTime;
}
上述代码定义了一个缓存访问事件，包含缓存名称、命中次数和操作耗时。标注后，JFR 能在运行时识别并记录该事件实例。
事件控制与采样策略
  • 使用 jcmd <pid> JFR.start 启动记录，并指定持续时间和采样间隔
  • 通过 threshold 参数过滤低价值事件，减少开销
  • 启用压缩（compress=true）优化磁盘写入
结合 JDK Mission Control 可对生成的 JFR 文件进行可视化分析，定位延迟高峰与资源瓶颈。

3.3 结合jstack和jcmd进行现场快照比对

在排查Java应用的线程阻塞或性能瓶颈时，结合使用`jstack`和`jcmd`可提供更全面的运行时视图。通过定期采集线程快照并进行比对，可以识别出长时间运行或卡顿的线程行为。
生成线程快照
使用以下命令分别获取同一时刻的线程信息： 

# 使用 jstack 生成线程转储
jstack -l <pid> > jstack_dump.log

# 使用 jcmd 发送 Thread.print 命令
jcmd <pid> Thread.print > jcmd_dump.log
上述命令中，`-l` 参数用于输出锁信息，`Thread.print` 是 `jcmd` 提供的等效功能，两者输出格式高度一致，便于文本比对。
差异分析定位问题线程
将两次采集的快照使用 diff 工具对比：
  • 持续处于 RUNNABLE 状态的线程可能占用CPU过高
  • 长期等待在某把锁（如 BLOCKED on java.util.concurrent）上的线程可能存在竞争
  • jcmd 输出包含额外VM信息，适合与 jstack 联合验证
通过交叉验证两种工具输出，可增强诊断结果的可信度。

第四章：内存泄漏案例深度剖析与修复策略

4.1 案例一：HTTP客户端滥用导致虚拟线程积压

在采用虚拟线程处理高并发请求时，若未对底层HTTP客户端进行适配优化，极易引发线程资源积压。典型的错误模式是使用阻塞式HTTP客户端（如传统URLConnection或未配置连接池的OkHttp）与虚拟线程结合。
问题代码示例

try (var client = HttpClient.newHttpClient()) {
    IntStream.range(0, 10_000).forEach(i -> {
        Thread.ofVirtual().start(() -> {
            var request = HttpRequest.newBuilder(URI.create("https://httpbin.org/delay/1")).build();
            client.send(request, HttpResponse.BodyHandlers.ofString()); // 阻塞调用
        });
    });
}
上述代码为每个虚拟线程创建一个同步HTTP请求，虽然虚拟线程本身轻量，但底层Socket连接未复用，导致大量TCP连接建立、超时与资源等待。
核心瓶颈分析
  • 缺乏连接池管理，频繁建连消耗文件描述符
  • 长时间响应使虚拟线程无法及时释放
  • 线程调度器负载激增，GC压力显著上升
正确做法是结合支持异步非阻塞的客户端（如Java 11+的HttpClient配合CompletableFuture）实现真正的协程化调用。

4.2 案例二：同步阻塞调用在虚拟线程中的连锁反应

虚拟线程虽能高效调度大量任务，但一旦遭遇同步阻塞调用，仍可能引发平台线程的级联阻塞。关键问题在于：阻塞操作会“钉住”底层平台线程，导致其他虚拟线程无法被及时调度。
阻塞调用示例

VirtualThread.start(() -> {
    try {
        Thread.sleep(5000); // 阻塞当前虚拟线程
        System.out.println("Task completed");
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
});
上述代码中，sleep 虽为模拟阻塞，但在真实场景如 FileInputStream.read() 或传统 JDBC 调用时，会真正占用平台线程资源，限制并发能力。
优化策略对比
调用类型是否阻塞平台线程推荐程度
异步I/O否高
同步阻塞I/O是低
结构化并发可控中
避免在虚拟线程中执行传统阻塞操作，是充分发挥其高并发优势的前提。

4.3 案例三：未受控的虚拟线程生成引发OOM

在采用虚拟线程实现高并发数据同步时，若缺乏对线程创建速率的有效控制，极易导致内存耗尽。
问题代码示例

for (int i = 0; i < Integer.MAX_VALUE; i++) {
    Thread.ofVirtual().start(() -> {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    });
}
上述循环持续创建虚拟线程并启动，尽管每个线程仅休眠一秒，但无限制的启动行为使JVM无法及时回收资源。
根本原因分析
  • 虚拟线程虽轻量，但仍占用堆内存用于栈帧和元数据
  • 未使用ExecutorService等机制进行限流
  • 垃圾回收速度远低于线程创建速度
最终，大量待执行或阻塞中的虚拟线程累积，触发OutOfMemoryError: Unable to create native thread。

4.4 从根源修复：结构化并发与作用域线程实践

现代并发编程的复杂性常源于任务生命周期管理混乱。结构化并发通过将并发操作绑定到明确的作用域，确保子任务不会脱离父任务的控制流，从而避免资源泄漏和竞态条件。
作用域线程模型
在该模型中，所有子线程必须在作用域内启动，并在作用域结束前完成。Java 的 StructuredTaskScope 提供了原生支持： 

try (var scope = new StructuredTaskScope<String>()) {
    Future<String> user = scope.fork(() -> fetchUser());
    Future<String> config = scope.fork(() -> fetchConfig());

    scope.join(); // 等待子任务完成
    return user.resultNow() + " | " + config.resultNow();
}
上述代码中，scope.fork() 启动作用域内的子任务，join() 阻塞至所有任务完成或超时。异常会统一抛出，便于集中处理。
  • 子任务受控于父作用域生命周期
  • 自动取消未完成任务，防止资源泄漏
  • 简化错误传播与超时管理

第五章：构建可持续监控的虚拟线程健康体系

监控指标设计原则
为保障虚拟线程在高并发场景下的稳定性，需建立以延迟、吞吐量和线程生命周期为核心的监控体系。关键指标包括活跃虚拟线程数、平台线程利用率、任务排队时长及异常中断频率。
  • 活跃虚拟线程数：反映当前调度负载
  • 平台线程阻塞率：识别I/O瓶颈
  • 任务提交与完成延迟差：衡量调度效率
集成Micrometer实现度量导出
使用Micrometer将JVM内置的虚拟线程数据暴露给Prometheus： 

MeterRegistry registry = new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);
Gauge.builder("jvm.virtual.threads.active")
     .register(registry, () -> Thread.getAllStackTraces().keySet().stream()
         .filter(t -> t.isVirtual())
         .filter(t -> t.getState() == Thread.State.RUNNABLE)
         .count());
告警规则配置示例
指标名称阈值条件告警级别
virtual_threads_pending_count> 5000 for 2mCRITICAL
platform_thread_blocked_duration_seconds95th percentile > 1sWARNING
可视化追踪链路整合
虚拟线程调用拓扑图

通过OpenTelemetry注入上下文，实现从平台线程到虚拟线程的任务追踪。

在某电商大促压测中，通过上述体系发现虚拟线程因数据库连接池不足导致大量阻塞，结合线程dump与慢查询日志定位至HikariCP配置不合理，调整后P99延迟下降76%。
QuickTrans
关注
JDK21（ZGC）的Arena陷阱，一招解决堆外OOM内存泄漏
张小凡
11-27 1936
本文记录了一次生产环境K8s容器OOM问题的完整排查过程。通过分析发现，虽然JVM堆内内存使用率正常（不足30%），但容器工作集内存（WSS）持续增长至4GB限制导致Pod重启。深入排查确定问题根源为glibc内存分配器的多线程arena机制导致堆外内存（inactive_anon）不断累积。解决方案是通过设置环境变量MALLOC_ARENA_MAX=4限制arena数量，并优化JVM参数使用容器感知的内存配置。优化后WSS稳定在3900MB左右，未再出现OOM重启。文章还提供了内存监控方法和相关优化建议。
堆外内存泄漏排查
liuhstop1的博客
06-07 1510
查看相关代码 涉及到这个调用的是 Jackson 的反序列化为 map 的时候 对 key 做了这个操作，用来减少内存占用空间。线上的兜底 job 服务监控显示每天以 1% 的速度内存增长，直到 90% 以上，需要手动重启。可以很明显看到主要是 Symbol 区 Stringtable 的增长 也就是 String.Intern 的调用。3. 使用 Java 的 Unsafe 类做一些分配本地内存的操作 不好控制 主要在 Intern 区。1. 禁用相关，重启后再进行观察，不再出现相关堆外内存泄漏。
堆外内存泄漏问题排查及解决
阿鑫你要努力啊的博客
04-24 3452
因为在Java中，每次使用javax.script.ScriptEngine进行脚本编译时，会创建一个新的ScriptEngine实例，如果这些实例无限制地被创建和保存在内存中，就会导致内存占用过多。只要通过线程名字，就能找到对应的程序代码，但对比分析了三天的jstack日志，写程序统计了各种线程的数量，分析增长变化。监控中看到内存使用率居高不下，但主要是堆外内存一直在持续增长，定位到应该是有堆外内存泄漏。通过dump文件分析，并无发现异常对象，而且堆内存使用正常，判断不是堆内存泄漏。
揭秘Java虚拟线程内存泄漏：3个关键指标让你提前预警
CodeIsle的博客
12-04 634
掌握百万并发下的 Java 虚拟线程内存管理技巧，揭秘内存泄漏的3个关键预警指标。适用于高并发微服务与云原生场景，通过线程堆栈监控、对象引用分析和GC行为追踪，提前发现隐患。高效稳定，值得收藏。
Java堆外内存泄露分析
热门推荐
编程的本质是数学问题
01-25 1万+
查看堆内存占用正常，jvm垃圾回收也没有异常。而top出来显示java占用内存是几个G，那么可能想到了是堆外内存泄漏。 需要安装google-perftools工具进行分析 1.先安装g++ 不然编译会报错：g++: command not found # yum -y install gcc gcc-c++ ---- 2.安装libunwind 不建议版本>0.99据说有问题，
[工作]堆外内存泄露分析，进程内存远超申请堆大小
Lord_sh的博客
04-28 741
最近工作中碰到了内存泄漏的问题 emmm， 这曲线还真挺恐怖的。 分析&解决过程： 一、 为啥没有fullGC ps -ef 看了下虚拟机参数，发现堆空间就开了8g，这曲线都涨到14g了，问了下同事，曲线显示的是进程内存（堆内内存+堆外内存），所以下面就分别看下堆内内存和堆外内存的情况了。 二、 堆内内存的情况 1. 先理解下内存模型 内存模型 // https:/...
java 堆外内存泄露排查
xglinux的博客
08-30 3412
内存泄露 堆外
堆外内存泄露
奋斗、
08-25 5757
原文：https://mp.weixin.qq.com/s?__biz=MzIzNzQzNjEwMw==&mid=2247484816&idx=1&sn=2e60a5afffcbcec401c10a3c85c91173&chksm=e8c9e838dfbe612e8134613b37bf739d22de242482a758dcfdbb55b0beff6c819e9bbb392f9d&mpshare
CentOs7网卡配置文件修改无效
06-28
代码转载自：https://pan.quark.cn/s/8ce4326d996e 对于在 CentOS 7 系统中修改网卡配置文件后无法使设置生效的情况，经过实践验证，可以通过使用 nmcli 命令来进行调整。完成修改之后，需要重新启动虚拟机以使更改生效，这样操作流程即告完成。如果设置仍然无法生效，则表明虚拟机在启动过程中所获取的 IP 地址配置并非针对 eth0，此时可以对其它网卡的配置文件进行修改或将其移除。在 CentOS 7 系统中，网络配置的管理机制与早期版本存在差异，主要体现为采用了 Network Manager 服务来负责网络接口的管理。在某些情形下，尽管修改了 `/etc/sysconfig/network-scripts` 目录下的 `ifcfg-eth0` 文件，但网络配置却未能即时生效。此类问题的发生通常源于 CentOS 7 采用了不同于以往的配置读取方法。接下来将具体阐述如何借助 nmcli 命令来处理这一挑战。 以 root 用户身份登录系统并打开终端界面。nmcli 是 Network Manager 提供的命令行界面工具，它支持在命令行环境下执行网络连接的建立、编辑、查询及管理任务。针对修改 eth0 网卡配置的需求，可以遵循以下步骤进行操作： 1. 导航至 `/etc/sysconfig/network-scripts` 目录： ``` cd /etc/sysconfig/network-scripts ``` 2. 检查该目录内是否存在 `ifcfg-eth0.bak` 文件，该备份文件可能是先前调整配置时遗留下来的，若存在可能造成冲突。若发现该文件，可以选择将其删除： ``` [root@localhost netw...
网络管理教程入门至精通软件.txt
06-28
代码转载自：https://pan.quark.cn/s/46fd08fb879c 网管教程 从入门到精通软件篇 ★一。★详尽的xp修复控制台指令及其应用!!! 放入xp（2000）的光盘，安装时选择R，执行修复！ Windows XP（涵盖 Windows 2000）的控制台指令是在系统遭遇某些意外状况时的一种极具效用的诊断、检测以及恢复系统功能的工具。笔者确实一直期望能够将这方面的指令进行归纳，此次由老范辛苦整理了这份极具价值的秘籍。 Bootcfg bootcfg 命令用于启动配置与故障恢复（对大多数计算机而言，即 boot.ini 文件）。 带有特定参数的 bootcfg 命令仅在运用故障恢复控制台时方可使用。能够在命令行界面下运用带有不同参数的 bootcfg 命令。 用法： bootcfg /default 设定默认引导选项。 bootcfg /add 向引导清单中增添 Windows 安装。 bootcfg /rebuild 重复整个 Windows 安装流程并让用户选择需添加的项目。 注意：运用 bootcfg /rebuild 之前，应先借助 bootcfg /copy 命令备份 boot.ini 文件。 bootcfg /scan 探查用于 Windows 安装的全部磁盘并展示结果。 注意：这些结果被静态存储，并用于当前会话。若在当前会话期间磁盘配置发生变动，为获取更新的探查结果，必须先重启计算机，然后再次探查磁盘。 bootcfg /list 列示引导清单中已有的项目。 bootcfg /disableredirect 在启动引导程序中禁用重定向。 bootcfg /redirect [ PortBaudRrate] |[ useBio...
Ansible playbook register参数详解[项目代码]
06-28
本文详细介绍了Ansible中register关键字的使用方法。register用于捕获任务输出并存储为变量，支持后续任务调用和条件判断。文章从基本用法入手，展示了如何通过shell模块注册变量并访问其stdout、stderr、rc等字段。接着讲解了基于register变量的条件判断，如使用stat模块检查文件存在性。针对复杂输出，介绍了通过Jinja2模板引擎访问嵌套字典和列表的方法，例如获取Docker容器状态。还涵盖了多任务注册，通过loop循环结合register批量处理文件检查。此外，文章说明了ignore_errors与register的配合使用，允许任务失败时仍捕获输出。最后通过实际示例演示了如何获取Python包列表并过滤版本号大于3.0的包。register功能强大，能显著提升Playbook的灵活性和健壮性。
鸿蒙App开发全流程实战[可运行源码]
06-28
本文介绍了《鸿蒙App开发全流程实战》一书，该书基于鸿蒙3.0操作系统，面向Web前端开发者，详细讲解了鸿蒙App开发的完整流程。内容涵盖鸿蒙操作系统背景、技术架构、开发环境搭建、JavaScript组件开发、分布式多终端App实战（如计划管理软件）、服务卡片、原子化服务、流转功能等。书中包含大量代码示例和视频讲解，并附赠源码及PPT。文章还提供了赠书活动信息，鼓励读者关注、点赞、收藏和评论以参与抽奖。作者为华为云特约编辑、CSDN博客专家，拥有丰富的开发经验。
易语言源码易语言考勤辅助工具源码
06-28
易语言源码易语言考勤辅助工具源码
YOLO算法英镑纸币目标检测数据集-400张-标注类别为二十英镑.zip
06-28
【注：该页面底部资源详情处，可查看数据集可视化效果】 1. YOLO目标检测数据集， 适用于YOLOV5、yolov7,yolov8, yolov11, yolov13, yolo26等系列算法，含标签，已标注好，可以直接用来训练，包含YOLO格式标签和VOC格式标签； 2. 内置data.yaml数据集配置文件，已经划分好了训练集、验证集等； 3. 数据集和模型具体情况可参考 https://blog.csdn.net/zhiqingAI/article/details/124230743?spm=1001.2014.3001.5502
摄像头AA制程-下载即用.zip
06-28
代码下载链接： https://pan.quark.cn/s/fc524f791b68 AA制程，即Active Alignment，被理解为主动对准，是一种用于确定零部件装配中相对位置的方法。在摄像头封装阶段，涉及图像传感器、镜座、马达、镜头、线路板等多个部件的重复组装，而传统的封装设备如CSP及COB等，均是依据设备设定的参数进行零部件的移动装配，因而零部件的叠加误差会逐渐增大，最终在摄像头上表现为拍照最清晰的位置可能偏离画面中心、四边清晰度不均等现象。伴随智能手机和其他高端电子产品的普及，摄像头模组的性能正日益受到重视。高分辨率、卓越的低光表现以及稳定视频输出是现代用户所期望的。在摄像头模组的制造环节，各部件的精准定位对成像质量具有决定性作用。因此，一种名为“AA制程”（Active Alignment）的前沿技术被开发出来，成为摄像头精密对准的核心技术。 AA制程，即Active Alignment，是一种在摄像头封装过程中应用的主动对准方法。该方法在多个组件装配阶段发挥作用，涵盖图像传感器、镜座、马达、镜头和线路板等部件。传统的封装方式，例如CSP（Chip Scale Package）和COB（Chip On Board），依赖于设备预设的参数进行组装，但随着组件数量的增加，误差也会累积，最终影响摄像头的表现。例如在成像质量上可能出现中心位置偏移、四角清晰度不一致等问题。 AA制程技术的核心在于实时监测与主动调整。在组装过程中，它借助先进的检测设备持续监控半成品的状态，并根据实时信息对组装部件进行精确修正，从而显著降低装配误差。通过这种技术，能够确保摄像头模组中各组件的相对位置准确无误，从而使得最终的成像效果更加稳定，特别是在中心区域和四角的清晰度上...
安卓程序古诗500首卡片式-墨韵诗笺安卓apk程序
06-28
在快节奏的数字时代，古诗词仿佛一缕清泉，润泽着浮躁的心灵。“墨韵诗笺”便是一款以水墨风格呈现的单机古诗词鉴赏应用，收录了从先秦到清代共 500 首经典诗词，旨在为用户打造一座掌上诗词桃源。它不仅提供了朝代分类浏览、卡片翻转译注、本地收藏书架等核心体验，更通过细腻的水墨视觉和流畅的交互，让古典之美在现代屏幕上复活。 ———————————————— 版权声明：本文为CSDN博主「海兰」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/hadoop_/article/details/162396551
Cisco Packet Tracer 校园网设计
06-28
打开链接下载源码： https://pan.quark.cn/s/a4b39357ea24 这是一个针对中小型校园网络环境的网络构建方案，借助Packet Tracer仿真软件来完成网络配置工作，并且融合了多种先进的技术手段。 在此方案中，通过运用VLAN技术来达成学校不同部门之间的网络区域划分；借助链路捆绑技术来增强核心层的网络传输速率与运行稳定性；借助RSTP协议来提升网络在发生故障时的切换效率，同时防止出现网络环路及广播风暴现象；借助思科公司的HSRP协议来确保网关设备的高可用性；通过设置ACL访问控制列表来管控不同部门网络之间的互访权限；通过部署NAT网络地址转换技术来处理内部网络设备访问外部网络和公网IP地址资源不足的情况；通过配置OSPF动态路由协议并结合默认路由引入功能，来确保内部网络设备之间的互联互通以及访问外部互联网的路径选择问题；同时在网络架构中集成了无线路由设备，为校园网络中的无线终端用户提供了WIFI接入服务。 该网络架构具备完善的各项功能，并且配置流程说明详尽，适合作为课程设计或毕业设计的参考范例，但未经合法授权严禁用于商业目的。
易语言源码易语言酷按钮模块3.2源码
06-28
易语言源码易语言酷按钮模块3.2源码
＜数据集＞yolo 垃圾桶满溢识别＜目标检测＞
最新发布
06-28
YOLO与VOC格式的垃圾桶满溢识别数据集，适用于YOLO系列、Faster Rcnn、SSD等模型训练，类别：overflow、garbage、garbage_bin，图片数量3349。文件中包含图片、txt标签、指定类别信息的yaml文件、xml标签，已将图片和txt标签划分为训练集、验证集和测试集，可直接用于YOLOv5、YOLOv6、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLOv11、YOLOv12、YOLOv13、YOLOv26等YOLO系列算法的训练。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值