尧图网站建设 
简介这是一套基于Java开发的人脸识别签到系统完整项目源码面向具备一定Java基础、希望将人脸识别技术落地到实际业务中的开发者与学习者。项目围绕无接触身份验证与签到流程展开整合科大讯飞、Face等主流人脸识别API覆盖人脸检测、特征提取、比对与活体检测等核心环节并涉及网络请求、图像处理与数据存储等Java技术要点。资源包共225个文件以65个java源码、78个xml配置、36个png界面素材及18个so库、14个jar依赖为主另有gradle构建脚本与说明文档压缩包约15.29MB目录结构完整便于按模块研读。目前已有292人学习下载。借助其中的Swface-master源码读者可参考API调用、返回数据处理与性能优化思路并了解隐私保护与错误处理等实践细节适合作为课程设计或二次开发的参考范例。1. 人脸识别签到系统 Java 落地从打卡排队到 300ms 识别的工程账公司前台那台人脸识别门禁机每天早上九点准时排起长队员工盯着屏幕等两秒才滴一声通过行政那边还抱怨导出考勤表要手动对照片。这个场景催生了用 Java 自建人脸识别签到系统的需求——不是做一个 demo而是能扛住早晚高峰、能对接现有 HR 系统、能在普通工控机上跑起来的生产工具。标题里的人脸识别签到系统_java拆开看是三件事人脸检测与特征提取的算法链路、Java 侧的服务编排与并发处理、签到业务的数据一致性。适合有 Java 基础、想把这套东西真正部署到公司或园区的中级开发也适合正在准备 java 面试题里高并发场景设计这类问题的工程师拿来当实战素材。下面按选型、实现、避坑、进阶四段推进每一步都落到能跑的代码和能调的参数上。2. 技术选型Java 侧人脸识别库怎么挑才不翻车2.1 三种主流方案的能力边界对比Java 本身不做图像推理必须借助 JNI 或 HTTP 调用底层引擎。市面上能落地的路线就三条纯 Java 实现的轻量库、JNI 封装 C 引擎、调云服务 API。纯 Java 方案里 EasyAI 人脸识别是常被搜到的关键词它把一些传统 CV 算法用 Java 重写好处是零依赖、maven 引进来就能跑坏处是精度和速度都停留在能用级别侧脸和戴口罩场景基本报废。ArcFace 人脸识别走的是另一条路底层是 C 的推理框架Java 通过 JNI 调 so 库精度能到工业级但部署时要处理动态库路径、CUDA 版本匹配这些脏活。云 API 最省事可早晚高峰每秒钟几十次调用网络延迟和按量计费两座大山压下来中小团队很难长期承受。我一般会这样分日签到量 200 人以内、对精度要求不苛刻的内部工具EasyAI 够用500 人以上、有口罩或逆光场景直接上 ArcFace 的 Java SDK已经有 GPU 服务器且团队有人懂 C 编译可以考虑自己封装 ONNX Runtime 的 Java binding。选型时别只看识别率那个数字要问三个问题模型文件多大、单次推理占多少内存、并发 10 路时 CPU 跑到多少。这三个数决定了你能不能把它塞进一台两千块的工控机。2.2 用 Maven 把依赖和模型文件管起来选定 ArcFace 路线后第一步是把 SDK 的 jar 和模型文件纳入构建流程。很多教程让你手动把 so 文件拷到java.library.path这在开发机上行得通一到 Docker 里就找不到库。正确做法是用 maven 的resources插件把模型和动态库打进 jar启动时解压到临时目录再加载。!-- pom.xml 片段把 native 库和模型文件作为资源打包 -- build resources resource directorysrc/main/resources/directory includes include**/*.so/include include**/*.onnx/include /includes /resource /resources plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /archive /configuration /plugin /plugins /build这段配置的作用是把src/main/resources下的.so和.onnx文件原样打进最终 jar。参数上注意includes要写全后缀漏了.dll在 Windows 开发机上就会报UnsatisfiedLinkError。打包后用jar tf target/xxx.jar | grep so确认文件在不在这一步能省掉后面两小时的排查。2.3 加载引擎时的路径处理与初始化参数jar 里的 so 文件不能直接被 JVM 加载得先落到磁盘。下面这段初始化代码是踩过坑之后稳定下来的写法。public class FaceEngineLoader { private static volatile FaceEngine instance; public static FaceEngine getInstance() throws IOException { if (instance null) { synchronized (FaceEngineLoader.class) { if (instance null) { // 从 classpath 读取 so释放到临时目录 String libName libarcface_jni.so; File tmp File.createTempFile(arcface, .so); tmp.deleteOnExit(); try (InputStream in FaceEngineLoader.class .getClassLoader().getResourceAsStream(libName); OutputStream out new FileOutputStream(tmp)) { byte[] buf new byte[8192]; int n; while ((n in.read(buf)) ! -1) { out.write(buf, 0, n); } } System.load(tmp.getAbsolutePath()); // 初始化参数检测阈值 0.5识别阈值 0.8线程数按核数 instance new FaceEngine(0.5f, 0.8f, Runtime.getRuntime().availableProcessors()); } } } return instance; } }逻辑上先做双重检查锁保证单例再把 so 从 jar 流式写到临时文件deleteOnExit保证 JVM 退出时清理。System.load必须传绝对路径传相对路径在 systemd 托管的服务里会失败。初始化参数里检测阈值 0.5 是宽松值适合签到场景——宁可多检几张脸让人重试也别漏检导致员工打不上卡识别阈值 0.8 是余弦相似度阈值低于这个值判为陌生人。线程数直接取 CPU 核数IO 密集的签到场景可以设成核数加一但别超过 16否则线程切换开销反而拖慢响应。3. 签到链路实现从摄像头取流到写库的完整代码3.1 用 JavaCV 拉 RTSP 流并抽帧签到系统的输入是摄像头不是本地图片。工控机上接 USB 摄像头可以用 OpenCV 的VideoCapture但园区场景多半是网络摄像头走 RTSP 协议。JavaCV 封装了 FFmpeg是 Java 侧拉流最稳的选择。// 拉 RTSP 流每 200ms 抽一帧送检测 public class CameraGrabber implements Runnable { private final String rtspUrl; private final FaceEngine engine; private final SignService signService; public CameraGrabber(String rtspUrl, FaceEngine engine, SignService signService) { this.rtspUrl rtspUrl; this.engine engine; this.signService signService; } Override public void run() { FFmpegFrameGrabber grabber new FFmpegFrameGrabber(rtspUrl); grabber.setOption(rtsp_transport, tcp); // 避免 UDP 丢包花屏 grabber.setImageWidth(1280); grabber.setImageHeight(720); try { grabber.start(); long lastGrab 0; Frame frame; while ((frame grabber.grabImage()) ! null) { long now System.currentTimeMillis(); if (now - lastGrab 200) continue; // 抽帧间隔 lastGrab now; ListFaceResult faces engine.detect(frame); for (FaceResult f : faces) { signService.trySign(f.getFeature(), f.getRect()); } } } catch (Exception e) { // 断流重连间隔 3 秒 try { Thread.sleep(3000); } catch (InterruptedException ignored) {} run(); // 简单重连生产环境建议用状态机 } } }rtsp_transport设成 tcp 是关键UDP 模式下网络抖动会导致画面花屏人脸检测直接失效。抽帧间隔 200ms 对应 5fps签到场景不需要 25fps 全帧率5fps 足够捕捉到人走到摄像头前的瞬间同时把 CPU 占用压到 30% 以下。grabImage返回的是解码后的帧如果摄像头是 H.265 编码要确认 FFmpeg 编译时带了对应解码器否则start()就抛异常。3.2 特征比对与签到判定的业务逻辑检测到人脸后核心是拿特征向量去底库比对。底库是员工注册时存下来的特征通常几百到几千条。暴力遍历在 1000 条以内还能接受超过就得建索引。Service public class SignService { private final MapLong, float[] featureStore new ConcurrentHashMap(); private final SignRecordMapper signMapper; public SignService(SignRecordMapper signMapper) { this.signMapper signMapper; } public void trySign(float[] feature, Rect rect) { long bestId -1; float bestScore 0f; for (Map.EntryLong, float[] e : featureStore.entrySet()) { float score cosine(feature, e.getValue()); if (score bestScore) { bestScore score; bestId e.getKey(); } } if (bestScore 0.8f) return; // 陌生人忽略 // 同一人 5 分钟内只记一次防重复签到 SignRecord last signMapper.findLatest(bestId); if (last ! null System.currentTimeMillis() - last.getTime() 300_000) { return; } signMapper.insert(new SignRecord(bestId, System.currentTimeMillis(), bestScore)); } private float cosine(float[] a, float[] b) { float dot 0, na 0, nb 0; for (int i 0; i a.length; i) { dot a[i] * b[i]; na a[i] * a[i]; nb b[i] * b[i]; } return (float) (dot / (Math.sqrt(na) * Math.sqrt(nb) 1e-8)); } }featureStore用ConcurrentHashMap是因为注册接口可能在运行时新增员工读写要线程安全。余弦相似度计算里加1e-8是防止零向量导致除零。5 分钟去重窗口是业务规则太短会漏掉员工中途外出再回来的签到太长会把下午的签到吞掉。这个值建议做成配置项不同公司考勤规则不一样。3.3 用 MyBatis 写签到记录并保证幂等签到记录表最怕重复插入。除了上面的时间窗口判断数据库层再加一道唯一索引兜底。-- 签到记录表唯一索引防止同一人同一分钟重复插入 CREATE TABLE sign_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL, sign_time BIGINT NOT NULL, score FLOAT NOT NULL, device_id VARCHAR(64), UNIQUE KEY uk_emp_minute (employee_id, sign_time) );sign_time存毫秒时间戳唯一索引建在employee_id和sign_time上。但毫秒级时间戳几乎不可能重复这个索引形同虚设。实际做法是把sign_time按分钟取整存一个sign_minute字段唯一索引建在employee_id和sign_minute上。插入时用INSERT IGNORE或ON DUPLICATE KEY UPDATE这样即使应用层去重失效数据库也不会产生脏数据。MyBatis 的 mapper 里写insert ignore into sign_record ...返回影响行数为 0 就说明是重复签到直接忽略。4. 避坑与排查人脸识别签到系统上线后最容易翻车的五件事4.1 现象早上第一个人能识别后面全失败原因通常是摄像头自动曝光没关。第一个人走到镜头前画面亮度突变摄像头自动调整曝光后面几秒画面过曝或过暗人脸检测直接失效。解决办法是在摄像头管理后台关掉自动曝光手动设一个适合室内灯光的曝光值。如果摄像头不支持就在 Java 侧加一个简单的亮度归一化用 OpenCV 的equalizeHist对灰度图做直方图均衡。4.2 现象识别率白天正常傍晚集体下降傍晚自然光斜射进大厅人脸一半亮一半暗特征提取出来的向量和注册时差异巨大。这是 ArcFace 这类模型的通病训练数据里侧光样本少。解决分两步注册时在多个光照条件下各采一张取平均特征识别时如果连续三次相似度在 0.6 到 0.8 之间触发补光或提示员工正对镜头。别指望调阈值能解决阈值降到 0.6 会把陌生人放进来。4.3 现象服务跑两天后内存溢出FFmpegFrameGrabber的Frame对象如果不手动释放堆外内存会持续增长。JavaCV 的Frame底层是PointerGC 管不到。正确做法是在每次循环末尾调frame.close()或者用try (Frame frame grabber.grabImage())这种自动关闭的写法。另外FaceEngine的检测结果里如果包含Mat对象也要手动release()。用jcmd pid VM.native_memory能看到堆外内存的走势涨到几个 G 不降就是这个问题。4.4 现象并发签到时段数据库连接池被打满早晚高峰几十个人同时走到不同摄像头前每个摄像头一个线程每个线程一次数据库写入。HikariCP 默认最大连接数 10瞬间就被占满后面的请求排队超时。解决是把签到写入改成异步识别成功后把记录丢进LinkedBlockingQueue单独一个消费者线程批量写库。批量大小设 50超时 200ms 强制刷出。这样数据库压力从每秒几十次降到每秒几次连接池 5 个连接就够。4.5 现象Docker 容器里启动报 UnsatisfiedLinkError本地跑得好好的一进容器就找不到 so。原因是基础镜像用了openjdk:8-jre-alpineAlpine 用的是 musl libc而 ArcFace 的 so 是 glibc 编译的根本不兼容。换成openjdk:8-jre-slim或eclipse-temurin:8-jre这类基于 Debian 的镜像。另外容器里要装libgomp1推理框架依赖 OpenMP 做并行计算缺了这个库会在加载模型时静默失败日志里只看到一句Engine init failed没有任何有用信息。5. 进阶技巧把识别延迟压到 300ms 以内的三个手段5.1 用线程池隔离检测和识别两个阶段检测找人脸框和识别提特征比对的计算量差一个数量级。检测每帧都要跑识别只在检测到人脸后才触发。如果串行执行一帧的处理时间等于检测加识别高峰期帧率掉到 2fps人走到镜头前要等一秒才响应。拆成两个线程池检测池 4 个线程识别池 2 个线程中间用ArrayBlockingQueue传人脸框。检测池持续消费摄像头帧识别池只处理有脸的帧。实测在 4 核工控机上端到端延迟从 800ms 降到 280ms。// 检测线程池和识别线程池分离 ExecutorService detectPool Executors.newFixedThreadPool(4); ExecutorService recognizePool Executors.newFixedThreadPool(2); BlockingQueueFaceResult faceQueue new ArrayBlockingQueue(32); // 检测线程持续抽帧检测结果入队 detectPool.submit(() - { while (running) { Frame frame grabber.grabImage(); ListFaceResult faces engine.detect(frame); for (FaceResult f : faces) { faceQueue.offer(f); // 队列满则丢弃不阻塞检测 } } }); // 识别线程从队列取做特征比对 recognizePool.submit(() - { while (running) { FaceResult f faceQueue.poll(100, TimeUnit.MILLISECONDS); if (f ! null) signService.trySign(f.getFeature(), f.getRect()); } });队列容量 32 是经验值太小会丢帧太大在识别跟不上时积压过期人脸。offer不阻塞队列满直接丢保证检测线程永远不被拖慢。识别线程用poll带超时避免空转烧 CPU。5.2 特征底库用 KD 树做近邻搜索底库超过 2000 人后暴力遍历的耗时开始显现。每次识别要算 2000 次余弦相似度单次 0.1ms累计 200ms占了总延迟的大头。换成 KD 树或 HNSW 索引把搜索复杂度从 O(n) 降到 O(log n)。Java 侧可以用smile库的KDTree或者自己实现一个简单的球树。注意人脸特征向量是 512 维KD 树在高维空间退化严重实际用 HNSW 效果更好。如果不想引额外依赖一个折中方案是把底库按部门分桶先定位部门再在桶内遍历2000 人分 10 个部门每次只算 200 次耗时降到 20ms。5.3 用本地缓存扛住重复识别同一个人站在摄像头前5fps 的抽帧意味着每秒被识别 5 次。如果每次都走完整比对加数据库查询纯属浪费。在SignService里加一层Caffeine缓存key 是人脸特征的哈希value 是员工 ID过期时间 10 秒。识别到人脸后先查缓存命中直接返回未命中再走比对。这样同一个人连续出现的 50 帧里只有第一帧走完整流程后面 49 帧都是内存命中。缓存大小设 500 条够覆盖高峰期同时在镜头前的人数。// Caffeine 缓存10 秒过期最多 500 条 CacheLong, Long faceCache Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.SECONDS) .maximumSize(500) .build(); public void trySign(float[] feature, Rect rect) { long hash Arrays.hashCode(feature); Long cachedId faceCache.getIfPresent(hash); if (cachedId ! null) { // 缓存命中直接走签到去重逻辑 doSign(cachedId, 1.0f); return; } // 缓存未命中走完整比对 long bestId searchBest(feature); if (bestId 0) { faceCache.put(hash, bestId); doSign(bestId, bestScore); } }Arrays.hashCode对 float 数组做哈希会有碰撞但碰撞概率极低且碰撞后只是多走一次比对不影响正确性。expireAfterWrite设 10 秒是因为同一个人不会在镜头前站超过 10 秒超时后重新比对能捕捉到人员更换。这套组合拳打下来4 核工控机、2000 人底库、5fps 抽帧的场景端到端延迟稳定在 300ms 以内早晚高峰不再排队。这套系统我从第一版跑通到稳定上线花了三周最大的教训是别在算法精度上死磕工程侧的抽帧策略、线程隔离、缓存设计对体验的影响比换个模型大得多。摄像头选型、光照处理、容器基础镜像这些外围问题才是决定项目能不能落地的关键。希望帮到你。本文还有配套的精品资源点击获取 Java人脸识别签到系统实战：从选型到300ms内识别
简介这是一套基于Java开发的人脸识别签到系统完整项目源码面向具备一定Java基础、希望将人脸识别技术落地到实际业务中的开发者与学习者。项目围绕无接触身份验证与签到流程展开整合科大讯飞、Face等主流人脸识别API覆盖人脸检测、特征提取、比对与活体检测等核心环节并涉及网络请求、图像处理与数据存储等Java技术要点。资源包共225个文件以65个java源码、78个xml配置、36个png界面素材及18个so库、14个jar依赖为主另有gradle构建脚本与说明文档压缩包约15.29MB目录结构完整便于按模块研读。目前已有292人学习下载。借助其中的Swface-master源码读者可参考API调用、返回数据处理与性能优化思路并了解隐私保护与错误处理等实践细节适合作为课程设计或二次开发的参考范例。1. 人脸识别签到系统 Java 落地从打卡排队到 300ms 识别的工程账公司前台那台人脸识别门禁机每天早上九点准时排起长队员工盯着屏幕等两秒才滴一声通过行政那边还抱怨导出考勤表要手动对照片。这个场景催生了用 Java 自建人脸识别签到系统的需求——不是做一个 demo而是能扛住早晚高峰、能对接现有 HR 系统、能在普通工控机上跑起来的生产工具。标题里的人脸识别签到系统_java拆开看是三件事人脸检测与特征提取的算法链路、Java 侧的服务编排与并发处理、签到业务的数据一致性。适合有 Java 基础、想把这套东西真正部署到公司或园区的中级开发也适合正在准备 java 面试题里高并发场景设计这类问题的工程师拿来当实战素材。下面按选型、实现、避坑、进阶四段推进每一步都落到能跑的代码和能调的参数上。2. 技术选型Java 侧人脸识别库怎么挑才不翻车2.1 三种主流方案的能力边界对比Java 本身不做图像推理必须借助 JNI 或 HTTP 调用底层引擎。市面上能落地的路线就三条纯 Java 实现的轻量库、JNI 封装 C 引擎、调云服务 API。纯 Java 方案里 EasyAI 人脸识别是常被搜到的关键词它把一些传统 CV 算法用 Java 重写好处是零依赖、maven 引进来就能跑坏处是精度和速度都停留在能用级别侧脸和戴口罩场景基本报废。ArcFace 人脸识别走的是另一条路底层是 C 的推理框架Java 通过 JNI 调 so 库精度能到工业级但部署时要处理动态库路径、CUDA 版本匹配这些脏活。云 API 最省事可早晚高峰每秒钟几十次调用网络延迟和按量计费两座大山压下来中小团队很难长期承受。我一般会这样分日签到量 200 人以内、对精度要求不苛刻的内部工具EasyAI 够用500 人以上、有口罩或逆光场景直接上 ArcFace 的 Java SDK已经有 GPU 服务器且团队有人懂 C 编译可以考虑自己封装 ONNX Runtime 的 Java binding。选型时别只看识别率那个数字要问三个问题模型文件多大、单次推理占多少内存、并发 10 路时 CPU 跑到多少。这三个数决定了你能不能把它塞进一台两千块的工控机。2.2 用 Maven 把依赖和模型文件管起来选定 ArcFace 路线后第一步是把 SDK 的 jar 和模型文件纳入构建流程。很多教程让你手动把 so 文件拷到java.library.path这在开发机上行得通一到 Docker 里就找不到库。正确做法是用 maven 的resources插件把模型和动态库打进 jar启动时解压到临时目录再加载。!-- pom.xml 片段把 native 库和模型文件作为资源打包 -- build resources resource directorysrc/main/resources/directory includes include**/*.so/include include**/*.onnx/include /includes /resource /resources plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration archive manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries /manifest /archive /configuration /plugin /plugins /build这段配置的作用是把src/main/resources下的.so和.onnx文件原样打进最终 jar。参数上注意includes要写全后缀漏了.dll在 Windows 开发机上就会报UnsatisfiedLinkError。打包后用jar tf target/xxx.jar | grep so确认文件在不在这一步能省掉后面两小时的排查。2.3 加载引擎时的路径处理与初始化参数jar 里的 so 文件不能直接被 JVM 加载得先落到磁盘。下面这段初始化代码是踩过坑之后稳定下来的写法。public class FaceEngineLoader { private static volatile FaceEngine instance; public static FaceEngine getInstance() throws IOException { if (instance null) { synchronized (FaceEngineLoader.class) { if (instance null) { // 从 classpath 读取 so释放到临时目录 String libName libarcface_jni.so; File tmp File.createTempFile(arcface, .so); tmp.deleteOnExit(); try (InputStream in FaceEngineLoader.class .getClassLoader().getResourceAsStream(libName); OutputStream out new FileOutputStream(tmp)) { byte[] buf new byte[8192]; int n; while ((n in.read(buf)) ! -1) { out.write(buf, 0, n); } } System.load(tmp.getAbsolutePath()); // 初始化参数检测阈值 0.5识别阈值 0.8线程数按核数 instance new FaceEngine(0.5f, 0.8f, Runtime.getRuntime().availableProcessors()); } } } return instance; } }逻辑上先做双重检查锁保证单例再把 so 从 jar 流式写到临时文件deleteOnExit保证 JVM 退出时清理。System.load必须传绝对路径传相对路径在 systemd 托管的服务里会失败。初始化参数里检测阈值 0.5 是宽松值适合签到场景——宁可多检几张脸让人重试也别漏检导致员工打不上卡识别阈值 0.8 是余弦相似度阈值低于这个值判为陌生人。线程数直接取 CPU 核数IO 密集的签到场景可以设成核数加一但别超过 16否则线程切换开销反而拖慢响应。3. 签到链路实现从摄像头取流到写库的完整代码3.1 用 JavaCV 拉 RTSP 流并抽帧签到系统的输入是摄像头不是本地图片。工控机上接 USB 摄像头可以用 OpenCV 的VideoCapture但园区场景多半是网络摄像头走 RTSP 协议。JavaCV 封装了 FFmpeg是 Java 侧拉流最稳的选择。// 拉 RTSP 流每 200ms 抽一帧送检测 public class CameraGrabber implements Runnable { private final String rtspUrl; private final FaceEngine engine; private final SignService signService; public CameraGrabber(String rtspUrl, FaceEngine engine, SignService signService) { this.rtspUrl rtspUrl; this.engine engine; this.signService signService; } Override public void run() { FFmpegFrameGrabber grabber new FFmpegFrameGrabber(rtspUrl); grabber.setOption(rtsp_transport, tcp); // 避免 UDP 丢包花屏 grabber.setImageWidth(1280); grabber.setImageHeight(720); try { grabber.start(); long lastGrab 0; Frame frame; while ((frame grabber.grabImage()) ! null) { long now System.currentTimeMillis(); if (now - lastGrab 200) continue; // 抽帧间隔 lastGrab now; ListFaceResult faces engine.detect(frame); for (FaceResult f : faces) { signService.trySign(f.getFeature(), f.getRect()); } } } catch (Exception e) { // 断流重连间隔 3 秒 try { Thread.sleep(3000); } catch (InterruptedException ignored) {} run(); // 简单重连生产环境建议用状态机 } } }rtsp_transport设成 tcp 是关键UDP 模式下网络抖动会导致画面花屏人脸检测直接失效。抽帧间隔 200ms 对应 5fps签到场景不需要 25fps 全帧率5fps 足够捕捉到人走到摄像头前的瞬间同时把 CPU 占用压到 30% 以下。grabImage返回的是解码后的帧如果摄像头是 H.265 编码要确认 FFmpeg 编译时带了对应解码器否则start()就抛异常。3.2 特征比对与签到判定的业务逻辑检测到人脸后核心是拿特征向量去底库比对。底库是员工注册时存下来的特征通常几百到几千条。暴力遍历在 1000 条以内还能接受超过就得建索引。Service public class SignService { private final MapLong, float[] featureStore new ConcurrentHashMap(); private final SignRecordMapper signMapper; public SignService(SignRecordMapper signMapper) { this.signMapper signMapper; } public void trySign(float[] feature, Rect rect) { long bestId -1; float bestScore 0f; for (Map.EntryLong, float[] e : featureStore.entrySet()) { float score cosine(feature, e.getValue()); if (score bestScore) { bestScore score; bestId e.getKey(); } } if (bestScore 0.8f) return; // 陌生人忽略 // 同一人 5 分钟内只记一次防重复签到 SignRecord last signMapper.findLatest(bestId); if (last ! null System.currentTimeMillis() - last.getTime() 300_000) { return; } signMapper.insert(new SignRecord(bestId, System.currentTimeMillis(), bestScore)); } private float cosine(float[] a, float[] b) { float dot 0, na 0, nb 0; for (int i 0; i a.length; i) { dot a[i] * b[i]; na a[i] * a[i]; nb b[i] * b[i]; } return (float) (dot / (Math.sqrt(na) * Math.sqrt(nb) 1e-8)); } }featureStore用ConcurrentHashMap是因为注册接口可能在运行时新增员工读写要线程安全。余弦相似度计算里加1e-8是防止零向量导致除零。5 分钟去重窗口是业务规则太短会漏掉员工中途外出再回来的签到太长会把下午的签到吞掉。这个值建议做成配置项不同公司考勤规则不一样。3.3 用 MyBatis 写签到记录并保证幂等签到记录表最怕重复插入。除了上面的时间窗口判断数据库层再加一道唯一索引兜底。-- 签到记录表唯一索引防止同一人同一分钟重复插入 CREATE TABLE sign_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, employee_id BIGINT NOT NULL, sign_time BIGINT NOT NULL, score FLOAT NOT NULL, device_id VARCHAR(64), UNIQUE KEY uk_emp_minute (employee_id, sign_time) );sign_time存毫秒时间戳唯一索引建在employee_id和sign_time上。但毫秒级时间戳几乎不可能重复这个索引形同虚设。实际做法是把sign_time按分钟取整存一个sign_minute字段唯一索引建在employee_id和sign_minute上。插入时用INSERT IGNORE或ON DUPLICATE KEY UPDATE这样即使应用层去重失效数据库也不会产生脏数据。MyBatis 的 mapper 里写insert ignore into sign_record ...返回影响行数为 0 就说明是重复签到直接忽略。4. 避坑与排查人脸识别签到系统上线后最容易翻车的五件事4.1 现象早上第一个人能识别后面全失败原因通常是摄像头自动曝光没关。第一个人走到镜头前画面亮度突变摄像头自动调整曝光后面几秒画面过曝或过暗人脸检测直接失效。解决办法是在摄像头管理后台关掉自动曝光手动设一个适合室内灯光的曝光值。如果摄像头不支持就在 Java 侧加一个简单的亮度归一化用 OpenCV 的equalizeHist对灰度图做直方图均衡。4.2 现象识别率白天正常傍晚集体下降傍晚自然光斜射进大厅人脸一半亮一半暗特征提取出来的向量和注册时差异巨大。这是 ArcFace 这类模型的通病训练数据里侧光样本少。解决分两步注册时在多个光照条件下各采一张取平均特征识别时如果连续三次相似度在 0.6 到 0.8 之间触发补光或提示员工正对镜头。别指望调阈值能解决阈值降到 0.6 会把陌生人放进来。4.3 现象服务跑两天后内存溢出FFmpegFrameGrabber的Frame对象如果不手动释放堆外内存会持续增长。JavaCV 的Frame底层是PointerGC 管不到。正确做法是在每次循环末尾调frame.close()或者用try (Frame frame grabber.grabImage())这种自动关闭的写法。另外FaceEngine的检测结果里如果包含Mat对象也要手动release()。用jcmd pid VM.native_memory能看到堆外内存的走势涨到几个 G 不降就是这个问题。4.4 现象并发签到时段数据库连接池被打满早晚高峰几十个人同时走到不同摄像头前每个摄像头一个线程每个线程一次数据库写入。HikariCP 默认最大连接数 10瞬间就被占满后面的请求排队超时。解决是把签到写入改成异步识别成功后把记录丢进LinkedBlockingQueue单独一个消费者线程批量写库。批量大小设 50超时 200ms 强制刷出。这样数据库压力从每秒几十次降到每秒几次连接池 5 个连接就够。4.5 现象Docker 容器里启动报 UnsatisfiedLinkError本地跑得好好的一进容器就找不到 so。原因是基础镜像用了openjdk:8-jre-alpineAlpine 用的是 musl libc而 ArcFace 的 so 是 glibc 编译的根本不兼容。换成openjdk:8-jre-slim或eclipse-temurin:8-jre这类基于 Debian 的镜像。另外容器里要装libgomp1推理框架依赖 OpenMP 做并行计算缺了这个库会在加载模型时静默失败日志里只看到一句Engine init failed没有任何有用信息。5. 进阶技巧把识别延迟压到 300ms 以内的三个手段5.1 用线程池隔离检测和识别两个阶段检测找人脸框和识别提特征比对的计算量差一个数量级。检测每帧都要跑识别只在检测到人脸后才触发。如果串行执行一帧的处理时间等于检测加识别高峰期帧率掉到 2fps人走到镜头前要等一秒才响应。拆成两个线程池检测池 4 个线程识别池 2 个线程中间用ArrayBlockingQueue传人脸框。检测池持续消费摄像头帧识别池只处理有脸的帧。实测在 4 核工控机上端到端延迟从 800ms 降到 280ms。// 检测线程池和识别线程池分离 ExecutorService detectPool Executors.newFixedThreadPool(4); ExecutorService recognizePool Executors.newFixedThreadPool(2); BlockingQueueFaceResult faceQueue new ArrayBlockingQueue(32); // 检测线程持续抽帧检测结果入队 detectPool.submit(() - { while (running) { Frame frame grabber.grabImage(); ListFaceResult faces engine.detect(frame); for (FaceResult f : faces) { faceQueue.offer(f); // 队列满则丢弃不阻塞检测 } } }); // 识别线程从队列取做特征比对 recognizePool.submit(() - { while (running) { FaceResult f faceQueue.poll(100, TimeUnit.MILLISECONDS); if (f ! null) signService.trySign(f.getFeature(), f.getRect()); } });队列容量 32 是经验值太小会丢帧太大在识别跟不上时积压过期人脸。offer不阻塞队列满直接丢保证检测线程永远不被拖慢。识别线程用poll带超时避免空转烧 CPU。5.2 特征底库用 KD 树做近邻搜索底库超过 2000 人后暴力遍历的耗时开始显现。每次识别要算 2000 次余弦相似度单次 0.1ms累计 200ms占了总延迟的大头。换成 KD 树或 HNSW 索引把搜索复杂度从 O(n) 降到 O(log n)。Java 侧可以用smile库的KDTree或者自己实现一个简单的球树。注意人脸特征向量是 512 维KD 树在高维空间退化严重实际用 HNSW 效果更好。如果不想引额外依赖一个折中方案是把底库按部门分桶先定位部门再在桶内遍历2000 人分 10 个部门每次只算 200 次耗时降到 20ms。5.3 用本地缓存扛住重复识别同一个人站在摄像头前5fps 的抽帧意味着每秒被识别 5 次。如果每次都走完整比对加数据库查询纯属浪费。在SignService里加一层Caffeine缓存key 是人脸特征的哈希value 是员工 ID过期时间 10 秒。识别到人脸后先查缓存命中直接返回未命中再走比对。这样同一个人连续出现的 50 帧里只有第一帧走完整流程后面 49 帧都是内存命中。缓存大小设 500 条够覆盖高峰期同时在镜头前的人数。// Caffeine 缓存10 秒过期最多 500 条 CacheLong, Long faceCache Caffeine.newBuilder() .expireAfterWrite(10, TimeUnit.SECONDS) .maximumSize(500) .build(); public void trySign(float[] feature, Rect rect) { long hash Arrays.hashCode(feature); Long cachedId faceCache.getIfPresent(hash); if (cachedId ! null) { // 缓存命中直接走签到去重逻辑 doSign(cachedId, 1.0f); return; } // 缓存未命中走完整比对 long bestId searchBest(feature); if (bestId 0) { faceCache.put(hash, bestId); doSign(bestId, bestScore); } }Arrays.hashCode对 float 数组做哈希会有碰撞但碰撞概率极低且碰撞后只是多走一次比对不影响正确性。expireAfterWrite设 10 秒是因为同一个人不会在镜头前站超过 10 秒超时后重新比对能捕捉到人员更换。这套组合拳打下来4 核工控机、2000 人底库、5fps 抽帧的场景端到端延迟稳定在 300ms 以内早晚高峰不再排队。这套系统我从第一版跑通到稳定上线花了三周最大的教训是别在算法精度上死磕工程侧的抽帧策略、线程隔离、缓存设计对体验的影响比换个模型大得多。摄像头选型、光照处理、容器基础镜像这些外围问题才是决定项目能不能落地的关键。希望帮到你。本文还有配套的精品资源点击获取