Java+OpenCV实现图片中的人脸识别

OpenCV是一个基于BSD许可（开源）发行的跨平台计算机视觉库，可以运行在Linux、Windows、Android和Mac OS操作系统上。它轻量级而且高效——由一系列 C 函数和少量 C++ 类构成，同时提供了Java、Python、Ruby、MATLAB等语言的接口，实现了图像处理和计算机视觉方面的很多通用算法 opencv采用C语言进行优化，而且，在多核机器上面，其运行速度会更快。它的一个目标是提供友好的机器视觉接口函数，从而使得复杂的机器视觉产品可以加速面世。

文件：url80.ctfile.com/f/25127180-739631245-c248ce?p=551685 (访问密码: 551685)

该库包含了横跨工业产品检测、医学图像处理、安防、用户界面、摄像头标定、三维成像、机器视觉等领域的超过500个接口函数。同时，由于计算机视觉与机器学习密不可分，该库也包含了比较常用的一些机器学习算法。或许，很多人知道，图像识别、机器视觉在安防领域有所应用。但很少有人知道，在航拍图片、街道图片（例如google street view）中，要严重依赖于机器视觉的摄像头标定、图像融合等技术。近年来，在入侵检测、特定目标跟踪、目标检测、人脸检测、人脸识别、人脸跟踪等领域，opencv可谓大显身手，而这些，仅仅是其应用的冰山一角。

这周有个朋友找到我，说他的程序出现了内存缓慢增长，没有回头的趋势，让我帮忙看下到底怎么回事，据朋友说这个问题已经困扰他快一周了，还是没能找到最终的问题，看样子这个问题比较刁钻，不管怎么说，先祭出 WinDbg。

二：WinDbg 分析

托管还是非托管泄露
一直关注这个系列的朋友都知道，托管和非托管的排查是两个体系，分析方式完全不一样，所以要鉴定是哪一块的内存问题，首先要用 !address -summary 观察进程的虚拟内存布局。

0:000> !address -summary

— Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
Free 710 7d9320465000 ( 125.575 TB) 98.11% <unknown> 7547 2409bea8000 ( 2.252 TB) 92.87% 1.76%
Stack 33363 2c1fae0000 ( 176.495 GB) 7.11% 0.13% Heap 1179 0126d3000 ( 294.824 MB) 0.01% 0.00%
Image 2988 00c274000 ( 194.453 MB) 0.01% 0.00% TEB 11121 0056e2000 ( 86.883 MB) 0.00% 0.00%
Other 11 0001d9000 ( 1.848 MB) 0.00% 0.00% PEB 1 000001000 ( 4.000 kB) 0.00% 0.00%

— Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED 7302 200071b1000 ( 2.000 TB) 82.47% 1.56% MEM_PRIVATE 45920 6ccc766000 ( 435.195 GB) 17.52% 0.33%
MEM_IMAGE 2988 0`0c274000 ( 194.453 MB) 0.01% 0.00%

— State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 710 7d9320465000 ( 125.575 TB) 98.11% MEM_RESERVE 12136 26c84ccf000 ( 2.424 TB) 99.94% 1.89%
MEM_COMMIT 44074 0`5aebc000 ( 1.421 GB) 0.06% 0.00%

从卦中看，当前进程的提交内存是 MEM_COMMIT= 1.4G， NT堆的内存占用是 Heap=294M，乍一看应该是托管内存泄露，接下来用 !eeheap -gc 观察托管堆。

0:000> !eeheap -gc
Number of GC Heaps: 12

Heap 0 (0000028577D73020)
generation 0 starts at 0x00000285B7000020
generation 1 starts at 0x00000285B6C00020
generation 2 starts at 0x0000028590800020
ephemeral segment allocation context: none
…

GC Allocated Heap Size: Size: 0x9598958 (156862808) bytes.
GC Committed Heap Size: Size: 0xea1c7e0 (245483488) bytes.

从卦中看很奇怪，托管堆也就 GC Committed Heap Size= 245M 的内存占用，说明问题不在托管堆上。

到底是哪里的泄露
这就是本篇文章的亮点之处，毕竟没有按照以前的套路出牌，接下来问题在哪里呢？还是得回头看下虚拟内存布局，终于你会发现 Stack 处很奇怪，内存占用高达 TotalSize =176G，内存段高达 RgnCount=3.3w，截图如下：

这两个蛛丝马迹已经告诉我们当前开启了非常多的线程，可以用 !address: -f:Stack 观察线程数和线程栈信息。

0:000> !address -f:Stack

    BaseAddress      EndAddress+1        RegionSize     Type       State                 Protect             Usage

  c0`80000000       c0`8104b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~139; 323a8.320a4]c0`8104b000       c0`8104e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~139; 323a8.320a4]c0`8104e000       c0`81050000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~139; 323a8.320a4]c0`81050000       c0`8209b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~140; 323a8.316b8]c0`8209b000       c0`8209e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~140; 323a8.316b8]c0`8209e000       c0`820a0000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~140; 323a8.316b8]...ed`460d0000       ed`4711b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~11119; 323a8.8b20]ed`4711b000       ed`4711e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~11119; 323a8.8b20]ed`4711e000       ed`47120000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~11119; 323a8.8b20]ed`47120000       ed`4816b000        0`0104b000 MEM_PRIVATE MEM_RESERVE                                    Stack      [~11120; 323a8.9828]ed`4816b000       ed`4816e000        0`00003000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE | PAGE_GUARD        Stack      [~11120; 323a8.9828]ed`4816e000       ed`48170000        0`00002000 MEM_PRIVATE MEM_COMMIT  PAGE_READWRITE                     Stack      [~11120; 323a8.9828]

从卦中看，当前线程高达 1.1w 个，有点吓人，终于算是找到源头了，

为什么会有 1w+ 的线程
接下来就需要鉴定下这些线程是托管线程还是非托管线程，可以用 !t 观察。

0:000> !t
ThreadCount: 11104
UnstartedThread: 0
BackgroundThread: 11099
PendingThread: 0
DeadThread: 4
Hosted Runtime: no
Lock
DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
20 1 32588 0000028577D0DB30 202a020 Preemptive 0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA
35 2 3262c 0000028577F3D000 2b220 Preemptive 00000285C0002660:00000285C0004008 0000028577529fc0 -00001 MTA (Finalizer)
36 4 326b4 0000028577F941B0 102b220 Preemptive 0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA (Threadpool Worker)
37 5 31848 000002857811A420 202b220 Preemptive 0000000000000000:0000000000000000 0000028577529fc0 -00001 MTA
…
11116 11100 966c 000002C620A45300 202b220 Preemptive 00000285C86CB910:00000285C86CD868 0000028577529fc0 -00001 MTA
11117 11101 95b4 000002C61B928970 202b220 Preemptive 00000285996DF978:00000285996E18D0 0000028577529fc0 -00001 MTA
11118 11102 9630 000002C61B928FC0 202b220 Preemptive 00000285996E1978:00000285996E38D0 0000028577529fc0 -00001 MTA
11119 11103 8b20 000002C620A465F0 202b220 Preemptive 00000285B46B15C0:00000285B46B3518 0000028577529fc0 -00001 MTA
11120 11104 9828 000002C61E014CB0 202b220 Preemptive 00000285C86CD910:00000285C86CF868 0000028577529fc0 -00001 MTA

从卦中看： DBG 和 ID 的编号相差无几，说明是大多是托管线程，从后面的 MTA 来看，这是一个 new Thread 出来的线程，接下来试探看下它有没有 Name，我们拿 ThreadOBJ=000002C61E014CB0 来看吧。

0:000> dt coreclr!Thread 000002C61E014CB0
…
+0x1c0 m_ExposedObject : 0x00000285`7821d160 OBJECTHANDLE__
…

0:000> !do poi(0x00000285`7821d160)
Name: System.Threading.Thread
MethodTable: 00007ffa63844320
EEClass: 00007ffa6379af48
Tracked Type: false
Size: 72(0x48) bytes
File: D:\root\NewWF\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffa63a0d608 4000b0d 8 …ExecutionContext 0 instance 00000285c0acf930 _executionContext
00007ffa64cbaa78 4000b0e 10 …ronizationContext 0 instance 0000000000000000 _synchronizationContext
00007ffa637afd00 4000b0f 18 System.String 0 instance 0000028590888a78 _name

0:000> !DumpObj /d 0000028590888a78
Name: System.String
MethodTable: 00007ffa637afd00
EEClass: 00007ffa6379a6e0
Tracked Type: false
Size: 98(0x62) bytes
File: D:\root\NewWF\System.Private.CoreLib.dll
String: Console logger queue processing thread

经过抽检，发现线程名都是 Console logger queue processing thread，看样子和日志有关系，接下来使用 ~*e !clrstack 查看当前所有线程，发现线程都卡在 ConsoleLoggerProcessor.TryDequeue 上，截图如下：

看样子和微软的控制台日志组件有关系，下一步就要观察源码。

从源码中寻找答案
导出源码后，利用 ILSpy 的代码回溯功能，发现是 ConsoleLoggerProcessor 类的构造函数 new 出来的线程，截图如下：

结合海量的重复线程栈，大概可以猜测到是代码将 Singleton 的模式改成了 Transient，导致不断的 new，不断的产生新的 Thread 去处理队列。

接下来我也懒得细究代码了，让朋友重点看一下 Microsoft.Extensions.Logging.Console 组件，朋友也很给力，终于找到了是 AppService 类在不断的 new 造成的，截图如下：

三：总结
这次事故如果朋友有专业的 APM 监控，相信很快就能发现 Thread 爆高的问题，从 dump 中用内存来反推线程爆高，确实有一点出乎意料。

这个 dump 的教训是：理解 Singleton 和 Transient 的利弊，尽量遵循官方文档的写法吧。