10 月 20 日，腾讯织云 Metis 智能运维学件平台在 OSCAR 开源先锋日上宣布，正式对外开源。Metis 是 AIOps （ Algorithmic IT Operations ），即智能运维领域的首个开源产品。智能运维主张通过算法从海量运维数据中学习摸索规则，逐步降低对人指定规则的依赖，进而减少人为失误。

OSCAR 开源先锋日由中国信息通信研究院主办，中国信通院云大所所长何宝宏，中国信通院云大所云计算部副主任栗蔚，腾讯云副总裁赵建春，腾讯云运营部总经理肖世广共同参与 Metis 开源发布仪式。

腾讯云副总裁赵建春表示：“人工智能与运维的结合有了 AIOps 的新概念，如何在智能运维领域寻求到新的突破，从传统 API 转向运维学件，将腾讯海量数量训练出来的模型贡献开源社区和业内，我想这就是织云 Metis 智能运维学件开源的意义，和大家共建 AI 运维场景，让人工智能和运维紧密结合。”

在“腾讯织云 Metis 智能运维学件平台”这一命名中，“学件”的概念由南京大学周志华教授提出。学件 = 模型 + 规约，具有可重用、可演进、可了解的特性。在此基础上，腾讯云副总裁赵建春先生进一步提出“运维学件”的概念，亦称 AI 运维组件，强调其具备对运维场景智能化解决方案的记忆能力。

“织云”指的是腾讯智能一体化运维平台，而“ Metis ”取名自希腊神话中的智慧女神墨提斯。随着互联网业务的急剧膨胀和服务类型的多样化发展，人为指定规则的不足之处逐渐凸显，促使近两年来智能运维领域的高速发展。织云 Metis 是聚焦在智能运维的应用实践集合，旨在通过一系列基于机器学习的算法，对运维数据进行分析、决策，从而实现自动化运维的更高阶段。

由于社交类业务种类丰富、规模庞大的特点，腾讯搭建了充足的 IT 基础设施，为实现多维度、深层次地运维公司各类业务在发展交互过程中产生的海量运维数据，Metis 应运而生。

如今，Metis 在运维质量、效率、成本三个方面都落地了众多智能运维实践，逐步构建出成熟的智能化运维场景，具体表现为质量保障、效率提升、成本管理、智能检测、通用模型和规则学习 6 个方面。

质量保障： 利用机器学习技术，进行异常检测、故障定位、瓶颈分析等，可在无人工干预下，智能地保障业务稳定运行。如无阈值智能监控、DLP 生死指标监控、多维根因分析。

效率提升：基于自然语言处理、机器学习技术，进行智能问答、智能变更、智能决策，可显著提升运维效率。如 Metis 的智能咨询机器人、舆情监控、集群智能负载均衡、数据库参数调优、容量预测。

成本管理：基于大数据智能分析技术，进行资源（设备、带宽、存储）管理，可迅速分析资源使用的明细，并通过横向大数据对比识别可优化点。如硬盘生命周期预测。本次 Metis 率先开源的无阈值智能监控学件，是从无监督+有监督学习的角度来解决时序数据的智能检测问题。

智能检测：运维人员不需要再去设置监控阈值，模型能够对异常情况做智能判决，直观告知检测结果是正常还是异常。通常而言，阈值的监控包含最值、同比、环比等维度设置，此检测方案在检测初期效果较好，但是随着业务发展和规模壮大，就会需要付出较高的人力成本去维护合适的阈值范围，对于大规模发展性业务得不偿失。智能检测的方案是基于统计判决、无监督和有监督学习对时序数据进行联合检测，通过统计判决、无监督算法进行首层判决，输出疑似异常，其次进行有监督模型判决，得到最终检测结果。这个过程就摒弃了阈值方式带来的问题。

通用模型：智能检测的模型由腾讯织云多元化的海量业务样本训练而成，比较适合复用在互联网行业的时间序列检测中。有监督的检测效果取决于标注样本的准确性和种类丰富性，通过样本库管理功能积累了大量的正负样本、分为测试集和训练集，通用模型是经过海量训练集的样本数据训练而来，涵盖较全面的样本分类。可以帮助一些用户避免掉缺乏训练数据所带来的难点，用户可直接加载通用模型进行检测。

规则学习：实践过程中也会遇到较个性的业务场景，千人千面，不同的用户对异常的判断标准也不尽一致，因此支持标注反馈功能，用户可根据标注信息进行训练，生成新的检测模型，进而掌握新的业务规则。

Metis 无阈值智能监控学件在腾讯内部已承载了超过 240 万个业务指标的异常检测，它经过海量监控数据的打磨，在异常检测和运维监控领域具有广泛的应用性，可取代传统的阈值检测方式，达到智能检测时序数据的异常，还能结合业务策略对异常数据进行告警推送。

秉承腾讯开源的理念，Metis 将打造一个开放的学件平台，陆续开源时间序列指标预测、主机异常智能分析、MySQL 异常智能分析、硬盘生命周期预测等其它智能运维学件，集合广大用户在智能运维领域的建设经验和实践，丰富完善针对质量、效率、成本三个方面的 AI 学件，搭建完备的运维场景，并将在未来兼容其它监控领域的开源产品，如 Zabbix、Nagios、Open-Falcon 等。

近年来，腾讯在开源社区越发活跃，自 2010 年起，腾讯对内采取“开放、共享、合力开发”的研发模式；对外实现自主开源，并积极参与社区工作，相继加入 Hyperledger、LF Networking 和开放网络基金会，成为 LF 深度学习基金会首要创始成员及 Linux 基金会白金会员。本次 Metis 开源，于腾讯，是其开放战略在技术领域的又一实践；于行业，则将填补智能运维领域的开源空白，并汇聚众力，促进运维技术的突破与发展。

从过去大半年的情况来看，中国手机厂商已经推出了不少让人印象深刻的 Android 手机设备，但在欧美地区，许多用户仍然不愿意将它们作为主力机使用。

其中很重要一点原因是系统和软件的问题。对他们而言，中国的 Android 手机系统过于花哨，而且功能臃肿，预装软件的类型和数量也和其它地区的不太相同。

为什么会有这种现象？

近期，The Verge 的编辑 Sam Byford  便发表了一篇题为《 How China rips off the iPhone and reinvents Android》的文章，以国外用户的视角，向我们描述了小米、vivo 和一加等中国手机厂商定制 Android 系统的现状，以及存在的一些问题。

很凑巧的是，这三者，也代表了目前中国三种主流的开发思路。

没有 Google，中国手机厂商只能做自己的服务

如果你想在中国制造 Android 手机，必须要面对一个现实问题：在这片土地，你没法使用和 Google 有关的大部分服务。

这意味着只要不通过特殊手段，大部分人没办法建立自己的 Google 账号，用不了 Google 地图，更不要说从 Play Store 上购买付费应用了。

在这种情形下，大部分中国手机厂商只能借助名为「AOSP」的 Android 开源项目，保留 Android 系统底层的同时开发自己软件功能，打造独立的账号体系，甚至是每家都有自己的应用商店。

而小米，便选择在一个恰当的时机进入市场，它通过 MIUI 起家，用互联网产品的节奏做好了一个 Android 定制系统。

Sam Byford 采访了英国的小米设计师 Robin，在他看来，智能手机的硬件和软件设计有着明显的不同，如果说硬件 ID 是关乎空间，那么软件设计就是关乎时间。

当设计一个大屏幕手机时，我们会寻求屏幕尺寸与手机体积之间的平衡，比如说让屏幕做的更薄一些。如果是软件，则要从用户体验和各种操作流程中来体现。

Robin 举了一个例子，当你启动应用前，你必须要先经历点亮屏幕并解锁手机的的过程，而 MIUI 则对过程中的动画和设计进行了修改，使其变得更简洁和精美，同样的，你在 MIUI 中也看不到原生 Android 中的应用抽屉设计。

事实上，这些定制功能对小米用户十分重要，他们喜欢在计算器中做各种换算，又或者是标注陌生来电，还有快速调用第三方应用接口的「传送门」，这可以看作是中国版的「Now on Tap」功能。

为了扩展海外市场，如今小米在开发 MIUI 系统时还要对中国用户和海外用户进行区分。比如在印度，小米就选择和当地的电商巨头 Paytm 合作提供二维码扫描，同时还和购物网站 Flipkart 合作的提供了直接从短信页面跳转到购物网站查看订单的特性。

而在拍照上，考虑到亚太地区的用户更喜欢磨皮等美颜效果，欧美地区则更追求自然，在服务好中国用户的同时，小米也要开发另一套方案。

让用户提出需求，并深入参与到软件设计过程中，实现软件系统的快速迭代，是小米手机和 MIUI 能够快速成长的一个重要原因。不可否认的是，它已经由当初的小众玩物变成了一个稳定可靠的大众系统，但伴随着版本数的不断迭代，MIUI 也需要面对臃肿和复杂的问题。

为什么要把系统做得和 iOS 一样？

中国并不是只有「小米模式」的存在，Sam Byford 还提及了 vivo 打造的 Funtouch OS。在他看来，vivo 更倾向于打造出色的硬件，但在软件系统层面却很少会进行核心功能的打造。

正因如此，即便 vivo 在今年打造出了一款“非常疯狂”的 NEX 手机，可它的系统里还是有 iOS 的影子。比如上滑的控制中心，已经不能用「纯属巧合」来形容了，这也不止是一家厂商的问题。

不过，考虑到中国数亿 iPhone 用户基数，vivo 仍然有这么做的理由。

一名 vivo 产品经理向 Sam Byford 表示，vivo 不会为了创新而创新，核心目标还是满足客户对最佳手机体验的需求，这自然就包含了使用微信，浏览网页，或是拍照听音乐等

vivo 目前的表现，是我们愿意倾听并理解消费者行为的结果，比如说相机，它的 UI 设计也要根据消费者的习惯来决定，最终通过测试找到最有效率的设计方法。

但这种决策并无法摆脱苹果的影子，更何况，这个所谓的「最佳手机体验」，很可能也是将 iOS 作为参照物的，毕竟苹果就是用出色的软件体验来辅助硬件差异化，这是苹果商业模式的关键。

基于这点，将产品的操作界面尽可能的模仿 iPhone，从商业层面考虑也确实有一定的意义。

一加 CEO 刘作虎就认为，很多厂商打造一个和 iOS 类似交互的系统，或许只是想让用户的换机门槛变得更低，这样就算是从 iPhone 换成一台 Android，交互逻辑还是一样的。

而小米的 Robin 也表示，苹果在这个行业拥有足够大的权威，更何况它也总是能创造出足够人性化的产品。

还有一点原因可能和微信有关。Ben Thompson 曾在去年撰写的《 Apple’s China Problem》中提及，在其它国家，让一名核心 iPhone 用户切换到 Android 品牌的手机是很困难的事，这意味着他要放弃很多苹果生态圈独有的体验。

可在中国地区，智能手机不存在太多的「换机成本」。中国的手机用户和微信绑定得很深，以至于这个绿色聊天应用更像是手机的系统核心，而不是 iOS 或 Android。

不过，最终是否要在 UI 和交互上摆脱掉 iOS 系统的影子，这依旧是一个值得思考的问题。

追求原生的可能性

在系统开发上，一加则代表了中国 Andorid 厂商的第三种方向——追求和 Google 相近的原生系统体验，即不会对功能做太多的修改以及自定义。刘作虎在接受 Sam Byford 采访中说：

我们希望提供一种无负担的体验，所以在系统层面会更追求轻便、流畅的部分，而不是盲目地加新功能，除非我们认为这项功能可以为用户增添更多价值。

事实也证明，这个理念同样能成为 Android 差异化的卖点。虽然一加手机在中国地区的销量不算很高，但在欧美地区却特别受欢迎。

对比三星 LG 等传统大牌厂商，一加手机可以在同等配置下给出更优惠的价格，而简洁流畅的 Oxygen OS 也是成功的关键因素。

在中国，一加选择开发了更加本土化的「氢OS」，在保留接近原生 Android 体验的同时，也包含了一些定制化的功能服务。

尽管一加的风格和其它厂商大相迳庭，但在刘作虎看来，中国用户对于手机系统的使用习惯已经发生了变化，这和其它地区的趋势是一致的：「大家都会对快速、流畅的体验提出更细分的要求，而不仅仅只是差异化或是个性化。」

只不过，变化是否真的会到来还不好说，这需要等待，也需要时间。

题图来源： Android Headlines

#欢迎关注爱范儿官方微信公众号：爱范儿（微信号：ifanr），更多精彩内容第一时间为您奉上。

爱范儿 |原文链接· 查看评论· 新浪微博

In the same vein of  my previous post on analyzing core dumps of .NET Core applications on Linux, let’s take a look at what it takes to do some basic performance profiling. When starting out, here are a few things I wrote down that would be nice to do:

• CPU profiling (sampling) to see where the CPU bottlenecks are
• Grabbing stacks for interesting system events (file accesses, network, forks, etc.)
• Tracing memory management activity such as GCs and object allocations
• Identifying blocked time and the block and wake-up reasons

With this task list in mind, let’s get started!

Collecting Call Stacks of .NET Core Processes

Generally speaking, a .NET Core application runs as a regular Linux process. There’s nothing particularly fancy involved, which means we can use  perf and ftrace and even  BPF-based tools to monitor performance. There’s just one catch: resolving symbols for call stacks. Here’s what happens when we profile a CPU-intensive application, running with defaults, using perf:

# perf record -F 97 -ag
^C[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.364 MB perf.data (789 samples) ]
# perf report

As you can see, debugging symbols are missing for pretty much everything under the dotnet process, so we only get addresses rather than method names. Fortunately, .NET Core ships with a knob that can be turned in order to get a perf map file generated in /tmp, which perf can then find and use for symbols. To turn on the knob,  export COMPlus_PerfMapEnabled=1:

$ export COMPlus_PerfMapEnabled=1
$ dotnet run &
[1] 23503

$ ls /tmp/perf*
/tmp/perf-23503.map  /tmp/perf-23517.map  /tmp/perfinfo-23503.map  /tmp/perfinfo-23517.map

$ head -2 /tmp/perfinfo-23517.map
ImageLoad;/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Private.CoreLib.ni.dll;{14b5688c-fe9a-4a0d-a0d1-b3af5439e23b};
ImageLoad;/home/vagrant/Runny/bin/Debug/netcoreapp1.1/Runny.dll;{ebb3ede4-dc41-44f4-93d3-152cd0b54ac0};

$ head -2 /tmp/perf-23517.map
00007FABB90D4480 2e instance bool [System.Private.CoreLib] dynamicClass::IL_STUB_UnboxingStub()
00007FABB90D44D0 2e instance System.__Canon /* MT: 0x00007FABB8F60318 */ [System.Private.CoreLib] dynamicClass::IL_STUB_UnboxingStub()

Equipped with these files, we can repeat the perf recording and then the report looks a bit better, with symbols starting to appear, such as  ConsoleApplication.Primes::CountPrimes. Note that because the .NET process wrote the perf map file, you might need to tell perf to ignore the fact that it’s not owned by root by using the -f switch ( perf report -f), or simply chown it.

Although, who reads perf reports anyway — let’s generate a flame graph!

Getting a Flame Graph

Well,  a flame graph is a flame graph, nothing special about .NET Core here once we have the right data in our perf files. Let’s go:

# git clone --depth=1 https://github.com/BrendanGregg/FlameGraph
...
# perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flame.svg

Here’s a part of the generated flame graph, looking pretty good:

If you look closely, you’ll notice that some symbols are still missing — notably, we don’t have any symbols for libcoreclr.so. And that’s just the way it is:

$ objdump -t $(find /usr/share/dotnet -name libcoreclr.so)
/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/libcoreclr.so:     file format elf64-x86-64

SYMBOL TABLE:
no symbols

If you build .NET Core from source, you can build with debug information, but that’s not what we get by default from the  Microsoft package repository.

Stacks For Other Events

Now that we have the necessary building blocks for getting symbols resolved, we can of course move on to other events (and use other tools, too).  For example, let’s trace context switches to see where our threads are getting blocked:

# perf record -e sched:sched_switch -ag
...
# perf report -f

(This is a fairly typical stack for where the thread gets preempted to let another thread run, even though it hasn’t called any blocking API.)

Or, let’s try some of my favorite tools from  BCC. For example, let’s trace file opens:

# opensnoop
PID    COMM               FD ERR PATH
1      systemd            17   0 /proc/955/cgroup
24675  dotnet              3   0 /etc/ld.so.cache
24675  dotnet              3   0 /lib/x86_64-linux-gnu/libdl.so.2
24675  dotnet              3   0 /lib/x86_64-linux-gnu/libpthread.so.0
24675  dotnet              3   0 /usr/lib/x86_64-linux-gnu/libstdc++.so.6
...
24689  dotnet             47   0 /home/vagrant/Runny/perfcollect
24689  dotnet             47   0 /home/vagrant/Runny/opens.txt
24689  dotnet             47   0 /home/vagrant/Runny/project.lock.json
24689  dotnet             47   0 /home/vagrant/Runny/.Program.cs.swp
24689  dotnet             47   0 /home/vagrant/Runny/Program.cs
24689  dotnet             -1  13 /home/vagrant/Runny/perf.data.old

We can conclude that everything more or less works. I dare say this is even a little easier than the JVM situation, where we need an external agent to generate debugging symbols. On the other hand, you have to run the .NET Core process with the  COMPlus_PerfMapEnabled environment variable at initialization time — you can’t generate the debugging information after the process has already started without it.

But then I tried one more thing. Let’s try to aggregate file read stacks by using the  stackcount tool from  BCC to probe  read in libpthread (which is where .NET Core’s syscalls are routed through on my box). The result is not very pretty:

$ stackcount pthread:read -p 29751
Tracing 1 functions for "pthread:read"... Hit Ctrl-C to end.
  read
  [unknown]
  [unknown]
  [unknown]
  [unknown]
  void [Runny] ConsoleApplication.Program::Main(string[])
  [unknown]
  [unknown]
  [unknown]
  [unknown]
  [unknown]
  coreclr_execute_assembly
  coreclr::execute_assembly(void*, unsigned int, int, char const**, char const*, unsigned int*)
  run(arguments_t const&)
  corehost_main
... snipped for brevity ...
    16

The [unknown] frames prior to Main are not very surprising — this is libcoreclr.so, and we already know it doesn’t ship with debuginfo. But the top-most frames are disappointing — this is a managed assembly, with managed frames, and there’s no reason why we shouldn’t be able to trace them.

To figure out where these frames are coming from, I’m going to need addresses. With the -v switch,  stackcountprints addresses in addition to symbols:

# stackcount pthread:read -v -p 29751
Tracing 1 functions for "pthread:read"... Hit Ctrl-C to end.
^C
  7f77b10b1680     read
  7f773651f267     [unknown]
  7f773651e8d5     [unknown]
  7f773651e880     [unknown]
  7f773651846a     [unknown]  7f77364bfb5d     void [Runny] ConsoleApplication.Program::Main(string[])
...

All right, so which module is 7f773651f267 in, for example? Let’s take a look at the loaded modules (I’m keeping only executable regions):

$ cat /proc/29751/maps | grep 'xp '
...
7f77364bf000-7f77364c6000 rwxp 00000000 00:00 0
7f7736502000-7f7736530000 r-xp 00003000 fd:00 787585                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll
7f7736534000-7f7736564000 r-xp 00003000 fd:00 787603                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.IO.FileSystem.dll
7f7736577000-7f7736578000 r-xp 00002000 fd:00 787665                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Threading.Thread.dll
7f773657a000-7f7736587000 r-xp 00002000 fd:00 787606                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.IO.dll
7f773658a000-7f773659a000 r-xp 00002000 fd:00 787668                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Threading.dll
7f773659d000-7f773659e000 r-xp 00002000 fd:00 787658                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Text.Encoding.dll
...

OK, so we seem to be making progress — the desired address is clearly in the range that belongs to System.Console.dll. But, being a managed assembly, we’re not going to find any debug information in it:

$ file /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll
/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll: PE32+ executable (DLL) (console) Mono/.Net assembly, for MS Windows

$ objdump -tT /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll
objdump: /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll: File format not recognized

Hmpf. So how are we supposed to get symbolic information for these addresses?

If you look online, you’ll find that there’s a tool on the .NET Core repos called perfcollect — essentially a Bash script for collecting performance information from .NET Core processes running on Linux. Let’s take a look.

The perfcollect Tool

The  perfcollect tool is fairly self-contained, and installs its own dependencies, most notably perf and  lttng — .NET Core on Linux uses LTTng to generate various events, including garbage collections, object allocations, thread starts, assembly loads, and many others. Then, perfcollect follows your instructions and runs perf and lttng to collect CPU sampling events, package them up to a big zip file, and hand that to you.

What are you supposed to do with that zip file?  Open it on Windows, apparently, using PerfView. Now,  I love PerfView, but a face palm is the only reasonable reaction to hearing this. What’s more, perfcollect does a bunch of work that you don’t really need if you plan to analyze the results on the same machine. But there’s  one thing it does which sounds very relevant:

WriteStatus "Generating native image symbol files"

# Get the list of loaded images and use the path to libcoreclr.so to find crossgen.
# crossgen is expected to sit next to libcoreclr.so.
local buildidList=`$perfcmd buildid-list | grep libcoreclr.so | cut -d ' ' -f 2`

That definitely sounds good! Turns out that .NET Core writes out an additional map file, named /tmp/perfinfo-$PID.map, which contains a list of image load events for your application’s assemblies. perfcollect then parses that list and invokes the crossgen tool to generate an additional perf map for each assembly, which can be fed into PerfView on the Windows side. Here’s what the perfinfo file looks like:

$ head -4 /tmp/perfinfo-29751.map
ImageLoad;/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Private.CoreLib.ni.dll;{14b5688c-fe9a-4a0d-a0d1-b3af5439e23b};
ImageLoad;/home/vagrant/Runny/bin/Debug/netcoreapp1.1/Runny.dll;{319d161b-f17e-44f6-a210-f297df920194};
ImageLoad;/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Runtime.dll;{819d412e-d773-4dbb-8d01-20d412b6cf09};
ImageLoad;/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/mscorlib.dll;{080dac22-6a0e-41ae-85fb-fb79cc07911b};

Now, that’s what crossgen is  supposed to do. And according to the comment above, crossgen is also  supposed to be in the same folder as libcoreclr.so. But it isn’t:

$ find /usr/share/dotnet -name crossgen

That’s right, no results. Looking online, it seems that crossgen is generated as part of a .NET Core build, and part of the CoreCLR runtime NuGet package, but it’s not part of the pre-packaged binaries you get from the Microsoft package repositories. But with a little effort  borrowed from the corefx repo, we can fetch our own crossgen:

$ export CoreClrVersion=1.1.0
$ export Rid=$(dotnet --info | sed -n -e 's/^.*RID:[[:space:]]*//p')
$ echo "{\"frameworks\":{\"netcoreapp1.1\":{\"dependencies\":{\"Microsoft.NETCore.Runtime.CoreCLR\":\"$CoreClrVersion\", \"Microsoft.NETCore.Platforms\": \"$CoreClrVersion\"}}},\"runtimes\":{\"$Rid\":{}}}" > project.json
$ dotnet restore ./project.json --packages .
... output omitted for brevity ...
$ ls ./runtime.$Rid.Microsoft.NETCore.Runtime.CoreCLR/$CoreClrVersion/tools
crossgen

All right! So we have crossgen, at which point we can try it out to generate debug information for System.Console.dll, or any other assembly we need, really. Here goes:

$ crossgen /Platform_Assemblies_Paths /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0 \
           /CreatePerfMap . /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll

Microsoft (R) CoreCLR Native Image Generator - Version 4.5.22220.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Successfully generated perfmap for native assembly '/usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll'.

What does this perfmap file look like? The same as any other perfmap, except the addresses are not absolute — they are offsets from the load address of that module:

$ head -4 System.Console.ni.\{3b33b403-e8c1-44af-a7fb-369b2603f2a3\}.map
0000000000017590 58 void [System.Console] Interop::ThrowExceptionForIoErrno(valuetype Interop/ErrorInfo,string,bool,class [System.Runtime]System.Func`2<valuetype Interop/ErrorInfo,valuetype Interop/ErrorInfo>)
00000000000175F0 4d void [System.Console] Interop::CheckIo(valuetype Interop/Error,string,bool,class [System.Runtime]System.Func`2<valuetype Interop/ErrorInfo,valuetype Interop/ErrorInfo>)
0000000000017640 82 int64 [System.Console] Interop::CheckIo(int64,string,bool,class [System.Runtime]System.Func`2<valuetype Interop/ErrorInfo,valuetype Interop/ErrorInfo>)
00000000000176D0 17 int32 [System.Console] Interop::CheckIo(int32,string,bool,class [System.Runtime]System.Func`2<valuetype Interop/ErrorInfo,valuetype Interop/ErrorInfo>)

Well, let’s see if we can at least resolve our desired address by using this approach. If you go back above, we were chasing the address 7f773651f267, loaded into System.Console.dll. First, let’s find the base address where System.Console.dll is loaded:

$ cat /proc/29751/maps | grep System.Console.dll | head -1
7f77364ff000-7f7736500000 r--p 00000000 fd:00 787585                     /usr/share/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Console.dll

The offset, then, is:

$ echo 'ibase=16;obase=10;7F773651F267-7F77364FF000' | bc
20267

So now we need to look for this offset in the System.Console map file. The closest match is here:

0000000000020150 286 instance valuetype System.ConsoleKeyInfo [System.Console] System.IO.StdInReader::ReadKey(bool&)

With that, we have one frame resolved! There are only a few more   This process begs to be automated. It would be great to automatically run crossgen, generate the map files with the relative addresses, convert them to absolute addresses, and merge them with the main /tmp/perf-PID.map file that other tools know and love. Read on!

dotnet-mapgen.py

Well, I wrote  a small script called dotnet-mapgen.py that automates the above steps and produces a single, unified map file that contains both JIT-compiled addresses and addresses that lie in crossgen’d (AOT-compiled) modules, such as System.Console.dll. The script has two modes:

$ ./dotnet-mapgen.py generate $(pgrep -n dotnet)
couldn't find crossgen, trying to fetch it automatically...
crossgen succesfully downloaded and placed in libcoreclr's dir
crossgen map generation: 15 succeeded, 2 failed

In the “generate” mode, the script first locates crossgen (downloading it if necessary, using the NuGet restore approach shown above), and then runs crossgen on all the managed assemblies loaded into the target process. The 2 failures in the above output are for assemblies that weren’t AOT-compiled. Note that this generation step can be done once, and the map files retained for subsequent runs — unless you change the set of AOT-compiled assemblies loaded into your process.

$ ./dotnet-mapgen.py merge $(pgrep -n dotnet)
perfmap merging: 14 succeeded, 3 failed

In the “merge” mode, the script calculates absolute addresses for all the symbols generated in the previous step, and concatenates this information to the main /tmp/perf-PID.map file for the target process.

There’s just one final problem. Turns out, perf refuses to use the map file for symbols that are in memory regions that belong to a module (in our case above, System.Console.dll). And there’s no way to convince perf that it should try to resolve such addresses using the map file. Fortunately, I have a bit more control over BCC tools, so I proposed a  PR for retrying symbol resolution using a map file if the symbol wasn’t resolved using the original module. With this patch, here’s  stackcount‘s output:

# stackcount ... pthread:read
Tracing 1 functions for "pthread:read"... Hit Ctrl-C to end.
^C
  read
  instance valuetype System.ConsoleKeyInfo [System.Console] System.IO.StdInReader::ReadKey(bool&)
  instance string [System.Console] System.IO.StdInReader::ReadLine(bool)
  instance string [System.Console] System.IO.StdInReader::ReadLine()
  string [System.Console] System.Console::ReadLine()
  void [Runny] ConsoleApplication.Program::Main(string[])
...
  16

Note how all symbols are now resolved to managed frames: the JIT-compiled Program::Main, and the AOT-compiled Console::ReadLine, StdInReader::ReadLine, and everything else.

Once this support lands in BCC, we can also do full-fidelity profiling with the  profile tool, stack tracing with  traceand  stackcount, blocked time analysis using  offcputime/ offwaketime, and a variety of other tools. For most purposes, the perf-based workflow shown in the beginning of the post is a poorer alternative, if you can run a recent-enough kernel with BPF support.

So Where Are We?

• We can use a variety of Linux performance tools to monitor .NET Core processes on Linux, including perf and BCC tools
• To resolve stacks and symbols in general, the COMPlus_PerfMapEnabled environment variable needs to be set to 1 prior to running the .NET Core process
• Some binaries still ship out of the box with no debug information (notably libcoreclr.so)
• Some managed assemblies aren’t included in the dynamic /tmp/perf-PID.map file because they were compiled ahead-of-time (using crossgen), and don’t contain debugging information
• For these assemblies, crossgen can generate map files that are sort-of useful, but can’t be used directly with perf
• The dotnet-mapgen script can automate the process of generating map files for AOT-compiled assemblies and merging them into the main map file for analysis
• BCC tools will be updated to support this scenario and enable full-fidelity tracing

In a subsequent post, I also plan to explore the LTTng traces to see if we can trace garbage collections, object allocations, managed exceptions, and other events of interest.

达利欧《原则》谈到“如果由你主持会议，应把握好对话”，深有感触，主持好会议不容易，这需要各种综合能力：时间管理、冲突管理、同理心、对企业文化的理解、集体心理学、强大的逻辑分析能力等。这里我以达利欧的建议为主线，谈谈我的个人理解。

1、明确主持人及会议服务对象

会议一定要以实现负责人的某个目标为目的！比如，我有一个方案，但我不确定它是否足够完备、合理，那么我的目的就是找持有不同意见的权威人士坐下来，以开放式辩论的方法达成目标；或者我希望把我的方案明确的表述给实现者，那么会议就应当以讲清楚方案、达成共识为主。

如果会议没有主持人，或者主持人没有明确的目标，那么这个会议一定是效率低下的。

2、表达要清晰准确，不要造成语言上的困惑

不同于编程语言是上下文无关的，我们的自然语言是有上下文相关性的。这个相关性不只是紧挨着的句子，还可能会跨度很长，还会包含大量的常识。所以，会议中的口头表达，要求与会者必须具备相应的上下文理解能力。请确保表达务必是清晰的。

在会议邀请（或者事后的会议纪要）的电子邮件中，把问题（及答案）清晰的记录下来是有必要的。

3、根据目标及优先级确定沟通方式

如果你需要开放式辩论，请务必挑选合适的参会者。因为辩论极其耗时，而且随着参与者人数的增多，耗时会成几何级数上升！所以一定要挑对人，这些参会者对你目标的完成最有帮助！挑选专业方向权威且与你观念不同的人是个好主意！在开放式辩论会议中，出现大家都不发言表达独立观点、或者个人拒不接受不同观点都是非常糟糕的。

如果A群体对目标实现的帮助非常大，B群体则可能有一些帮助，我不建议把A、B两群人放在一场开放式辩论会议中，而应该第一场先与A群体进行会议，第二场再与B群体。这会大大提高效率。

4、主持讨论时要果断、开明

所谓果断，就是判断一场讨论可能会耗时很久，但达成的结论对会议的目标达成没多少帮助，那么就应该果断停止讨论！例如产品评审会上，因为市场调研数据不足，可能出现研发挑战方案的执行意义，此时主持人必须快速判定这次讨论对完成方案落地的帮助有多大。有时参会者因为经验缺乏，他提出的问题主持人在剖析他提出的逻辑时有助于帮助他深化理解，如果时间允许这是值得的。

人的系统一（或者叫快系统，或者叫情绪系统，或者叫潜意识）总是倾向拒绝不同的意见（这很能提升内心自洽），主持人以及参与讨论的人必须牢记： 与负责任的权威不同意见交锋，对自己是最有收获的。

5、在不同层面的讨论对话中穿梭对照

会议讨论中会有两类问题：一类是具体问题，另一类则是方法论、原则。前者是一个萝卜一个坑，后者则是会对今后一类相似问题持续产生影响。所以后者明显更重要，后者应该持续的在工作中加以改进。在讨论中一定不时在这两类问题中转换，我们必须飞快的意识到当下究竟是在讨论具体问题还是方法论原则，如果是后者优先级应当更高，结论也需要更慎重。

6、谨防“跑题”

会议中出现长时间跑题一定是会议主持者的锅！就参会者来说，“跑题”是必不可免的，所以主持者有责任提醒、管理当前正在进行的讨论。有必要的话，可以通过投影仪或者白板把会议所有议题展示给所有参会者，包括已经达成共识和未达成共识的议题（已经达成共识的结论被参会者再刨出来讨论是极浪费时间的）。

7、坚持对话的逻辑性

出现冲突的双方为了维护自身的内心自洽很容易启动情绪攻击，此时很难做到对事不对人。相对来说，如果我们始终保持自己表达的意见是有内在逻辑性的，则很容易避免情绪影响共识达成的情形。一般在会议中，有参会者表达“我觉得···”并且接下来把这一假设事实当成其他结论的论据，那么这一定是缺乏逻辑性的。比如，“我觉得有些用户会觉得我们的产品···，所以我们的产品不应该···”，这种讨论一定会引发冲突！

讨论务必要建立在事实的基础上！

8、防止“责任分散效应”

有些共识在会议中达成了共识，可是会议主持人却没有把工作分解并分配到个人，他可能默认参会者既然一致达成了结论，那么就会各自知道承担怎样的责任。这是错误的，心理学中有“责任分散效应”，这在1964年美国的一起杀人案里首次发现。纽约深夜一位酒吧工作归来的女性，在公寓下被歹徒用刀刺死，案发过程持续三十分钟，有38位邻居发现却无一人报警。事后对美国引发了巨大的震动，大家都在讨论大城市的人性冷漠，而记者采访这38位邻居得到的回答是：每个人都以为别人会报警，所以见死不救并不会引发内心的罪恶感。心理学家后续做了大量类似的实验，发现当个体认为责任是群体的，最终是没有人负责的。

因此 主持人有义务分派、明确参会者个体的责任。

9、运用两分钟法则避免表述被持续打断

有些讨论激烈的会议中，可能出现有人的表达频繁被别人打断的场景。此时，主持者有义务让每位意见表达者至少拥有2分钟的时间，可以完整的表述清楚自己的想法。

10、注意气场强大的“快嘴王”

有的参会者对自己的观点坚信不疑，且他们很难被人说服，说话语速快，而且可以把这些特点外放表现出，强力推动会议进程，不给其他人认真思考和质疑的机会。此时主持人必须回到自己的目的上来，会议的目标达成有没有被阻碍？快嘴王很容易对语速慢、担心出错出丑的参会者产生影响。主持人应确保参会者能够畅通的提出疑问。

11、让每一个议题有始有终

如果议题的讨论持续很久却没有达成任何结论，这是对大家时间的极大浪费。即使议题的最终结论未达成，也应该记录下中间结果。所以，对议题的总结是必不可少的，也应当以会议纪要的方式发送给全体参会者。

12、活用各种沟通手段

沟通是耗时的，挨个一对一私下沟通是低效的。并不是除了一对一私下沟通外，只能通过在会议中沟通，就像第2点所说，会议时间几乎是与参与辩论者数量的平方成正比的。我们可以善用公司内的沟通工具，例如wiki、论坛、邮件、公告等，把握信息分享的有效性。

无论大小公司里，总会遇到低效的会议（大公司里会更多），参加这样的会议我总是感觉自己以及多数参会者在 浪费生命，时间就是生命嘛！但是，人又不适合一心多用，我们的大脑带宽是很低的，如果同时处理多件事，比如又在听会议发言，又在写代码，还在回邮件，一定是每件事都做不好，而且会感受很疲劳！企业文化应当扼杀这样的会议。

做一个高效的会议主持者并不容易，既要达成目的，也要少浪费大家的生命，故而特意写了这篇文章，希望与大家共勉！

健身是人类的刚需，但很长一段时间以来，国内的健身业态发展缓慢，几乎一成不变，虽屡有新健身品牌进入市场，但总体而言换汤不换药。

与人性博弈，传统健身房套路深

传统健身房的年卡制度和靠规模取胜商业模式，意味着需要更频繁的铺店，销售出售的年卡越多，会员办的年数越久，健身房前期收获的现金流就越大。

这决定了其与会员之间存在一种长久的心理博弈，健身房赌的是你的恒心和毅力，不幸的是获胜的一方绝大时候都是健身房。

“游泳、健身了解一下”，大部分人被舌灿莲花的销售安利办卡后，会想着自己很快就可以拥有八块腹肌或翘臀、马甲线，但理想很丰满，现实很骨感，坚持一个月的有，两个月少。

有3年健身经验的Allen告诉我们，自己近三年就办过三张健身卡，因为时间原因，或者是太懒，前前后后去的次数并不多，其中两张过期白白浪费了，一张目前正打算低价转让给朋友。

《经济学人》在一篇文章中曾提到过一个很惊人的数字， 60%的健身房会籍持有者，在入会后第二个月就放弃了自己的健身大业。

意料之外，也是情理之中，国内实现情况可能比60%还要高，深圳中心区某健身教练表示，自己所在的健身房很少有人会坚持一年以上，大部分人在办卡来过一两次之后就很难再见到。

囿于传统健身本身的反人性设计，消费者去健身房需消耗大量时间和精力来达到健身效果，加上价格不菲的私教课，让人望而怯步，大多人的健身计划都虎头蛇尾，难以付诸行动。

科技让健身更简单？来头不小的EMS健身

实际上，按次售卖的精品健身工作室近年来也屡见不鲜，但依旧解决不了人性（懒惰）的问题，目前这种模式也很难成气候。

不过，这种现状目前正在被慢慢改变，中国的健身创业者们试图在传统健身房的运营模式之外，尝试更多种可能。

与精品健身工作室的不愠不火相比，近年流行起来的科技健身来头不小， 用高科技设备满足人们健身的心理需求和实现健身效果。

有网友在小红书日记中分享， 在上海新天地逛街时体验过一次ZESPEED的EMS健身后，回来她在朋友圈表示“很简单的动作，但做完浑身酸痛到连走路都难，出了好多汗，酸爽”。

据介绍，EMS（Electrical Muscle Stimulation 肌肉电刺激）健身的核心是一套高科技健身设备，依靠发出模拟人体大脑生物电来信号，将中低频率脉冲电流导入到运动神经，通过调控脉冲电流的强度、频率、间歇时间等因素刺激肌肉协同工作，来加速血液循环，提高健身效率。

EMS最早的起源是防止肌肉萎缩，在国外运动康复领域已有几十年的应用，据临床试验证明，其增肌效果十分显著。

在健身教练的指导下配合有氧和无氧动作，主要以拉伸、深蹲、高抬腿等基本动作配合正确的吐纳为主，EMS健身在对运动量以及动作的要求不高的基础上就能够达到同时训练到全身各部位肌肉群的目的，从而达到减脂塑形的目的。

实际上，类似ZESPEED的EMS健身最大的卖点是健身20分钟相当于常规3-4小时的运动效果，省时、省力，对于像Allen这样的都市年轻人来说是一种新选择。

不过，患有严重的神经疾病、癫痫、血液循环障碍、肺结核糖尿病患者，以及肝脏疾病和对电极敏感的人群不可使用EMS训练。

国内EMS健身品牌生存现状

自2016年国内EMS健身品牌ZESPEED把德国EMS设备和技术引入国内后，直接推动和引领了国内EMS健身行业的快速发展，从最初的寥寥数家，今年已出现十几家EMS品牌。

目前，国内以EMS为核心的健身品牌且获得资本投资的有ZESPEED、安体倍力、K-EMS。

ZESPEED 为一普体育旗下的EMS健身品牌，除了ZESPEED外， 一普体育还拥有高端健身品牌 ZPLUS 和健身教育机构一普学院。

ZESPEED所使用的设备品牌为德国的Miha Bodytec，以直营店为主，同时还有合伙人店和共创空间店。

一普体育于2016年在FIBO与Miha Bodytec签订协议，将EMS正式引入中国，成立ZESPEED做科技健身市场的引领者

其标准化的ZE极速运动站，单店配备两台设备，五个教练，100平米场地，即可实现全时段的营业，用户按月卡购买，线上预约，单次价格在300-400不等，店内同时配置储物柜和淋浴间。

为打破场地空间约束，多场景的呈现，ZESPEED最小的门店可以做到30平米，2台机器，从单店模式上看，规模化复制裂变能力更强。

目前，ZESPEED在上海、北京等地开店11家，未来布局会从一线城市上海与北京的直营，经由合伙人与技术授权模式的推广进入二三线城市，计划三年开店到1000家，目前其大部分门店已达到盈亏平衡点。

据透露，ZESPEED已于今年7月份获得数千万PreA轮投资,目前正在进行A轮融资。

另一品牌安体倍力于18年获得天使轮投资1000万，其使用的EMS设备品牌为德国的Amplitrain，运营品牌为Fastall，目前上海和北京各有一家直营门店。

目前，EMS健身虽然发展迅速，但相比整个巨大的健身市场，还有很大的市场空间等待挖掘。

鱼龙混杂，健身业新贵们面临的新挑战

从游泳健身了解一下，到20分钟相当于常规3、4小时的运动效果，科技在健身中起到的作用越来越重要。

但不可否认的是，EMS在为健身行业带来革新的同时，也暴露出诸多问题。

目前，国内EMS健身行业存在的主要问题是市场教育和公众认知，EMS健身虽在国外已得到了临床与市场验证，但对国人来说，还属于新鲜的舶来品，人们对此的疑虑尚未解除。

失去了运动健身的真正乐趣，有消费者表示还是更喜欢去传统的健身房撸铁，在他看来，EMS健身虽然省时省力但失去了健身的乐趣。

实际上，类似这样对新技术抱怀疑情绪的人不在少数，在网上有人就对电脉冲健身的安全性表示担忧，会不会有什么风险。

不容忽视的事实是，在国内的EMS健身行业，从兴起到快速发展，越来越多的品牌和资本都参与其中，成熟品牌较少，行业口碑不一。

一个首要的风险是设备的安全性问题，市场上EMS健身设备良莠不齐，缺乏较成熟的经过医学验证的国产设备。

可以预见的是，设备标准和质量不一，消费者的安全将存在很大隐患，从长远来看，这对于整个行业发展有很大阻碍作用。

目前，国际上较权威的EMS设备制造商有德国Miha Bodytec公司，其在运动与医疗相关器械已经有40多年历史，有超过12年的专业运动设备研发生产经验，是全球最大的EMS设备品牌。

Miha Bodytec公司与德国大学建立EMS健身运动教学与培训体系，建立全球EMS行业标准，其旗下EMS产品Miha bodytec在德国有超过1000家工作室与俱乐部使用在欧洲市场占有率超过85%, 使用国家超过45个。

对于EMS健身来讲，另一个需要突破的难题是，相比于传统健身的互动氛围浓厚，EMS健身的内容单一也是阻碍人们积极尝鲜的一个重要原因。

网上有体验过EMS健身的部分网友表示，虽然EMS健身的时间很短，效果不错，但和之前健身房的动感单车或者团体操相比的话，总感觉略显枯燥。

对此，国内很多品牌目前的解决方案是，拓展更多的健身内容和课程，以满足消费者的需求。

以行业领头羊ZESPEED为例，教研团队根据不同健身人群的特征推出6类不同的课程，包含辣妈课程、美臀课程、跑者课程、腰腹课程、下背舒展课程以及中老年强化课程，所有EMS课程都经过国际第三方百年权威机构认证。

ZESPEED首创太空舱已申请外观设计专利

工作人员表示，今后随着用户数据的持续收集与需求的深入挖掘，平台会对这6类课程做更新迭代，研发更多课程内容。

此外，ZESPEED还从数据维度切入，为用户提供了“基因检测”与“便携式EMS设备”。

面对业态的变化和市场的需求，在行业诸多问题面前，EMS健身品牌们面临的是一场持久考验，这更多挑战的是品牌的运营能力。

在吸引更大规模的用户参与进来之前，EMS品牌们首先要解决的是如何统一设备的标准，规范和统一课程的权威认证，以及开发出更多好玩、实用的内容，能否解决这些问题，将是决定EMS健身能否走的更远的关键。

全民健身已来，科技健身方兴未艾

今年是第10个全民健身日，在魔性健身歌声“燃烧我的卡路里”伴奏下，想要健身塑型的人越来越多。

早在2016年，国务院就印发了《国务院关于印发全民健身计划（2016—2020年）的通知》，将全民健身上升为国家战略。

以上通知提到，到2020年全国体育消费总规模将达到1.5万亿元，全民健身成为促进体育产业发展、拉动内需和形成新的经济增长点的动力源。

随着健身市场越来越大，健身产业的发展也百花齐放，可以肯定的是，在ABC（AI、Big Data、Cloud Computing）时代，科技健身将扮演一个越来越重要的角色。

但类似于EMS这样的朝阳健身项目，在得到资本市场的认可后，如何在商业市场得到大众的普遍认可还有很长的一段路要走。

旷视科技CEO印奇曾说，“2018将是行业整合的一年，输赢到今年结束就能看得清楚。”

在距离2018年结束还有两个多月的今天，旷视科技安防事业部技术总经理那正平再次肯定了印奇的“预判”。

“在经历了众多大大小小的“战役”之后，这个行业内的玩家基本已经固定了，尤其是安防领域，无论是传统安防厂商还是AI创业公司，那些没有掌握行业的核心技能且管理水平欠佳的公司一定会出局，而其他的创业者们再想入局也难度极大。”

拥有15年IT从业经历的那正平，自2003年硕士毕业后，一直任职大唐电信，历任开发部门经理、公司副总经理等职务。其对公安、消防、政府应急管理信息化及应急指挥信息化了解透彻，并于2017年加入旷视科技，负责制定智能安防技术架构及发展战略。

身为一位行业老兵，那正平亲身经历了海康威视、大华股份等如今安防巨头们的成长过程。

“那个时候大唐电信正值发展巅峰时期，而海康、大华还嗷嗷待哺，所以双方一直都有接触、合作，但没想到他们发展的太快了，短短数十年就获得了傲视群雄的行业地位。”

看到技术对于行业的改变如此之大、之快，久坐传统深院的那正平心中也有了几丝起伏，可惜他一直未能发现一个让他眼前一亮以足矣让其做出改变的技术点。

直到去年，他真正感受到AI时机已至，自己多年的项目、行业经验可以帮助企业走得更远，帮助自己实现更高目标，于是毅然辞职选择加盟顶尖AI计算机视觉创业公司——旷视科技。

彼时，头部几家AI创业公司做安防业务算法足够、粮草齐备，可以说什么都不缺，最缺的就是像那正平那样对技术、业务、产品、项目都非常熟悉的全才，所以在人工智能领域形成了人才卖方市场，企业的待遇、成长空间和发展潜力都成为人才流向的关键因素。

怎么选呢？这是摆在那正平面前的一道难题。

作为一位在垂直行业扎根多年、负责过多个国家级重大项目的专家，他最终选择了旷视科技。

他说，眼下的AI赛道鱼龙混杂，市场上的AI初创公司如果单纯只做图像、语音识别这些通用技术，指望通过SDK获利，未来的路只会越来越窄。

相反，找到一个最适合自己的垂直领域，深扎进去做端到端的解决方案，把技术转化为产品，然后销售出去实现商业变现，再通过客户反馈更多的数据，从而夯实自身技术的途径，才是最现实的。

而就这一点而言，在安防领域能够做到的AI创企屈指可数，而旷视可以说是其中相对较好的一家。

七年经营，产品矩阵全面展开

提到旷视安防，行业内的人应该都有所耳闻。 

目前整体估值超过35亿美元的旷视科技是国内第一批将AI技术应用落地到传统安防行业中的独角兽企业。 

七年前，AI还未成风口，创业公司也没几家，VC圈尚不认可，那个年头，做AI已经要有难得的孤注一掷的情怀，不曾想入场后不久，旷视便瞄准了行业公认的硬骨头：安防市场。 

人们疑惑、不解甚至是嘲笑。毕竟彼时行业内更多的观点认为AI不过是新壶装老酒，老生常谈，落地应用乃至于商业化会有个漫长的过程，技术应用泡沫巨大。也有一些行业客户认为既然在十年前上了人脸识别的当，以后再也不会相信这一套玩意儿。 

旷视对此并未理会，在这一垂直领域扎下根去。当旷视用一个接一个的战果证明技术已经成熟了的时候，行业才真正地认识到：AI时代真的来了。 

经历，折射出一个嗷嗷待哺的创业公司从婴儿到长大最真实的样子，而当他呱呱坠地时，商业画卷也便渐渐展开。

技术落地前期，他的一哭一笑、一举一动、一吵一闹都被人们等待着，都被时代注视着，也被历史画卷记录着，时代的声音勾勒着他们的轮廓，越来越细，越来越多。 

终于在他成熟之际，那幅画的线稿也就清晰地展示在人们面前。 

今天，旷视安防所研发的产品矩阵涉及人、车、物特征识别等多个领域；业务线涉及 云、边、端三大版块。 

在云端，旷视利用大数据和深度学习算法，研发出集成数据可视化功能和轨迹追踪功能的城市天眼2.0系统及洞鉴5.0系统，相当于为行业用户搭建了云端研判平台。例如，结合城市安防、城市治理、城市交通、虚拟化治理和社会化服务五大场景，旷视的天眼系统可以帮助城市管理者实现智能、高效的管控。

在边缘计算领域，为满足安防实战场景的现实需求，旷视也在持续研发、优化算法以适配边缘计算的要求，将计划在2018年安博会期间推出全新的适配轻量云计算的近十款边缘生态展示方案和蕴含旷视优质算法算力的产品。这其中便包含具备4K分辨率超高清画质的4K结构化相机，和能够进行300人脸高并发抓拍的高密人脸抓拍平台，以及具备深度学习能力的敏观抓拍识别一体机和集抓取、识别、对比报警能力为一体的“最强大脑魔方”B3单芯片16路视频分析盒。 

而在终端，旷视为了满足各类复杂场景的实际需求打造出了形态各异的智能硬件产品，例如旷视敏观系列全结构化相机C4N-888，据说是业界首款能够实现人车识别的结构化相机；还有被旷视内部成为“快捕”系列的便携2.0——一种可机箱分离式升级版警务处理布控设备，以及集成旷视最新人脸识别算法而研发的“锐眸”系列智能眼镜等。 

可以说，在传统安防拥抱人工智能的当下，旷视正在用软硬一体的方式打造涵盖“算法、技术、硬件产品、解决方案、数据”在内的全价值链。

“这些产品矩阵都是实际存在的，也都是会经受市场考验的，2018年北京安博会上，针对以上三大块，旷视会分别集中展示并现场测试。”那正平说道。 

“毫不夸张地说，现在已经有多个省市都适配了旷视科技基于视频结构化技术的智能视频侦查系统，我们帮助公安部门抓获了在逃人员和犯罪嫌疑人数千名，AI技术正被越来越多行业人所认可。”

之所以能够在不长的时间内获得较为不错的成绩，在那正平看来，原因非常多元，最为重要的因素有两条： 

一是做事情的人，想要做好智能安防业务需要将传统安防人、AI人、互联网人都聚集在一起，之后，企业要有良好的机制将这三类人更好地融合在一起。 

比如互联网人C端思维比较明显，传统安防人更趋向市场驱动技术，而AI人更倾向技术驱动市场。当各类人由于思维不同出现观点碰撞时，领导层需要充分利用这三类人的思维成果并反馈出一个最有可能成功的信息，为用户打造技术更精、更优也更符合需求的产品。

二是原创技术领先性。从算法角度来说，太多依靠开源框架微创新，然后采用低价策略抢占市场，导致整个行业丧失了做基础原创技术创新动力的案例。 

坚持自研是一条漫长且艰苦的路，没人知道数年的努力能不能换得一次数量级的提升，也没人知道高投入后是否得到与之相匹配的回报。 

毕竟AI技术研发周期长，投入大，落地难，市场需从无到有进行培训，而最后的商业化也只能听天由命，大概率成了先烈还赔了岁月。

幸好，旷视花了七年时间让原本心存鄙见的人都转头做了AI、让原本不温不火的市场瞬间热情四涨、让更多人知道了AI，让人们知道了安防还可以这样玩。 

可以说，在安防领域取得的巨大成功已经可以看做是旷视高新科技成功转化的一个优秀案例。

持续原创，解锁更多AI场景

在AI火遍大江南北之后，当原创AI技术的领先性一次又一次地冲击着传统安防的敏感神经时，“点到为止”技术论又频频出现。

支持者认为，基于安防行业自身天然的高试错率，小数点后的算法精度数量级提升对于项目的最终归属没有大的改变。

在那正平看来，“现阶段，与安防相关的AI技术精准度还远远没有达到天花板，基于安防场景的不断变化，其对算法迭代的要求一定是非常严苛且上升的。

在这个市场中，谁能够看到算法精度提升解锁的更多场景，并根据场景的变化做到最为快速且精准的反应，谁就能在未来竞比中走得更远。”

眼下，AI在安防领域的研究应用主要针对几个核心问题：分别是分类检测、分割、以及对整个图像区域分类。 

以往来看，AI神经网络中激活函数、非线性单元、权重矩阵的应用形成了非常高维的非线性函数，从而可以完成非常复杂的任务；与此同时，在这基础之上，GPU的出现让神经网络的发展如虎添翼。

即便如此，相关AI技术在安防市场上的应用还存有几个挑战： 

认知问题相较感知问题较难解决。感知问题可以用神经网络函数逼近，相比之下认知问题解决起来比较棘手。 

比如如何教会机器辨识一把椅子。如果定义为四条腿，很多椅子并不满足此描述；如果定义为可以坐的物体，如此也行不通。所以说简单的检测物体问题上，背后都蕴含着更深层次的认知问题，如今很多问题还尚未解决。

在弱线索、遮挡、模糊、对象追踪等情况下，人类在识别的过程中通常会依据常识，并加入丰富的想象及推理。但是想要将这些能力传授给机器便非常困难；即使实现，识别能力与人类相比也相差甚远。

计算机视觉技术带给机器的能力不只是用来观察世界，而是需要与世界建立联系，从而一起做交互。在某个机器人去解决一件重要的问题需要用到手眼协同时，需要连续的关键决策，而不停地观察、决策和控制，这是机器智能目前非常难做到的事情。 

随着安防行业的多元化发展，未来很多细分场景对于精度要求之高势必让人咂舌，基于背景知识的图像内容描述，挑战都非常巨大。

也就是说，AI在安防行业的探索才刚刚开始，如果仅具备应用于现有部分场景中的技术和产品储备，接下来在这个市场比拼中会比较被动。

鉴于此，旷视所坚持的战略是通过原创的深度学习和智能感知技术构建基于人工智能核心技术的行业物联网和城市大脑。针对安防业务中的典型场景和实战诉求，旷视创新提出了覆盖“情、指、勤”全业务流程的“端到端”立体业务设计，针对每个环节的特点和痛点研发对应的产品及解决方案，建设以人工智能技术为核心的的智能安防基础物联感知体系，帮助传统安防实现数字化、智能化转型。

旷视安防的野望

“智能安防市场发展越来越快，各个甲方在选型时也会往AI上靠拢。传统安防公司大都往后端做，而AI公司则大力往前做，未来针对这个市场的比拼会非常精彩。”

今天的安防开足了马力，从原来的幕后自然生长，变成了台前极速狂奔。同时，今天的安防本质已经发生变化，它再也不局限于监控，而延伸到医疗、政务、教育各个领域。 

以AI技术为代表的高新技术的发展为人们提供了越来越多的可能性，而用户也出现了需求个性化的趋势。 

作为领先的科技赋能者，旷视科技正在两者之间找到一个平衡，利用技术将两者更加紧密地结合在一起，打造一个数字化、智能化的商业世界。

“在安防这条赛道上，眼下各个玩家跑的都非常快，需要注意的是，创业公司从0到1的发展过程中，一定要知道什么是自己该做的，什么是自己坚决不能碰的，一定要有差异化，尽量减少犯错。”

就安防来说，那正平坦言，旷视也有自己严格的业务底线与标准：做收敛型业务，发散性业务不做；做强AI业务，弱AI业务不做；可以体现差异化的做，体现不了差异化的不做。 

“为什么旷视科技能够七年如一日保持创新、一直进步？”我问。 

“旷视一直坚持技术信仰和价值务实。作为一家以人工智能技术为核心的创业公司，我们既要保持对AI技术的赤子之心，也要保持对应用场景的好奇与探索，真正让技术实现落地，持续为客户和社会交付价值。”

那正平答道。雷锋网雷锋网雷锋网

雷锋网 AI 科技评论按：本文是追一科技潘晟锋基于谷歌论文为 AI 科技评论提供的解读稿件。

最近谷歌研究人员通过新的BERT模型在11项NLP任务中夺得STOA结果，这在自然语言处理学界以及工业界都引起了不小的热议。作者通过在33亿文本的语料上训练语言模型，再分别在不同的下游任务上微调，这样的模型在不同的任务均得到了目前为止最好的结果，并且有一些结果相比此前的最佳成绩得到了幅度不小的提升。作者的这一研究其实是今年深度学习在自然语言处理中一个新热点方向的延续，故事还得从更早一点说起。

BERT的“前任”们

早在2015年的时候，微软研究院的何恺明和他的同事们发表了残差网络的论文，第一次通过残差的方式将卷积神经网络推进到了100层以上，并在图像识别的任务上刷新了当时的最高纪录。自那以后起，随着网络不断地加深，效果也在不断提升。然而大量的数据训练出来的大型网络虽然效果更好，但随着网络的加深以及数据集的不断扩大，完全重新训练一个模型所需要的成本也在不断地增加。

因此在计算机视觉处理中，人们越来越多地采用预训练好的大型网络来提取特征，然后再进行后续任务。目前这种处理方式已经是图像处理中很常见的做法了。

相比之下，自然语言处理目前通常会使用预训练的词向量来进行后续任务。但词向量是通过浅层网络进行无监督训练，虽然在词的级别上有着不错的特性，但却缺少对连续文本的内在联系和语言结构的表达能力。因此大家也希望能像图像领域那样，通过大量数据来预训练一个大型的神经网络，然后用它来对文本提取特征去做后续的任务，以期望能得到更好的效果。其实这一方向的研究一直在持续，直到今年的早些时候AllenAI提出的[ELMo](https://arxiv.org/pdf/1802.05365.pdf)由于其在后续任务上的优异表现获得了不小的关注。

在CMRC2018阅读理解比赛中，追一科技的参赛方案就运用了ELMo模型的预训练方式，并做了相应的改进。因为原本的ELMo当中对英文进行了字符级别的编码，但这对中文并不适用。我们在此基础上改进为笔画级别的编码，同时结合原有的词级别编码一起通过双层LSTM变换来进行语言模型预训练。经过实验验证，最后选择了512维的词级别ELMo向量进行后续任务。

在ELMo获得成功以后不久FastAI就推出了[ULMFiT](https://arxiv.org/abs/1801.06146)，其大体思路是在微调时对每一层设置不同的学习率。此后OpenAI又提出了[GPT](https://blog.openai.com/language-unsupervised/)。预训练的语言模型是在百度15亿词文本的语料上进行的，模型参数选择了12层，12head的Transformer结构。然后采用此模型直接在子任务上微调来进行后续任务。

从上面提及的这些论文的结果以及学界和工业界的反馈来看，这种使用大量的语料进行预训练，然后再在预训练好的模型上进行后续任务训练，虽然训练方式各有不同，但在后续任务都有不同程度的提高。

而谷歌提出的BERT就是在OpenAI的GPT的基础上对预训练的目标进行了修改，并用更大的模型以及更多的数据去进行预训练，从而得到了目前为止最好的效果。

Trransformer的编码器结构

BERT的主体结构和创新点

BERT模型沿袭了GPT模型的结构，采用[Transfomer](https://arxiv.org/abs/1706.03762)的编码器作为主体模型结构。Transformer舍弃了RNN的循环式网络结构，完全基于注意力机制来对一段文本进行建模。

Transformer所使用的注意力机制的核心思想是去计算一句话中的每个词对于这句话中所有词的相互关系，然后认为这些词与词之间的相互关系在一定程度上反应了这句话中不同词之间的关联性以及重要程度。因此再利用这些相互关系来调整每个词的重要性（权重）就可以获得每个词新的表达。这个新的表征不但蕴含了该词本身，还蕴含了其他词与这个词的关系，因此和单纯的词向量相比是一个更加全局的表达。

Transformer通过对输入的文本不断进行这样的注意力机制层和普通的非线性层交叠来得到最终的文本表达。

Transformer的注意力层得到的词-词之间关系

GPT则利用了Transformer的结构来进行单向语言模型的训练。所谓的语言模型其实是自然语言处理中的一种基础任务，其目标是给定一个序列文本，预测下一个位置上会出现的词。

模型学习这样的任务过程和我们人学习一门语言的过程有些类似。我们学习语言的时候会不断地练习怎么选用合适的词来造句，对于模型来说也这样。例如：

  > 今天天气不错，我们去公园玩吧。

这句话，单向语言模型在学习的时候是从左向右进行学习的，先给模型看到“今天天气”两个词，然后告诉模型下一个要填的词是“不错”。然而单向语言模型有一个欠缺，就是模型学习的时候总是按照句子的一个方向去学的，因此模型学习每个词的时候只看到了上文，并没有看到下文。更加合理的方式应该是让模型同时通过上下文去学习，这个过程有点类似于完形填空题。例如：

  >今天天气 { }，我们去公园玩吧。

通过这样的学习，模型能够更好地把握“不错”这个词所出现的上下文语境。

而BERT对GPT的第一个改进就是引入了双向的语言模型任务。

此前其实也有一些研究在语言模型这个任务上使用了双向的方法，例如在ELMo中是通过双向的两层RNN结构对两个方向进行建模，但两个方向的loss计算相互独立。追一科技在文本意图模型中，也加入了通过上下文预测某个词的辅助任务，通过实验发现在做意图分类的同时加入这个辅助任务能够让编码器尽可能的包含输入文本的全局信息，从而提高意图判断的准确率。

而BERT的作者指出这种两个方向相互独立或只有单层的双向编码可能没有发挥最好的效果，我们可能不仅需要双向编码，还应该要加深网络的层数。但加深双向编码网络却会引入一个问题，导致模型最终可以间接地“窥探”到需要预测的词。这个“窥探”的过程可以用下面的图来表示：

从图中可以看到经过两层的双向操作，每个位置上的输出就已经带有了原本这个位置上的词的信息了。这样的“窥探”会导致模型预测词的任务变得失去意义，因为模型已经看到每个位置上是什么词了。

为了解决这个问题，我们可以从预训练的目标入手。我们想要的其实是让模型学会某个词适合出现在怎样的上下文语境当中；反过来说，如果给定了某个上下文语境，我们希望模型能够知道这个地方适合填入怎样的词。从这一点出发，其实我们可以直接去掉这个词，只让模型看上下文，然后来预测这个词。但这样做会丢掉这个词在文本中的位置信息，那么还有一种方式是在这个词的位置上随机地输入某一个词，但如果每次都随机输入可能会让模型难以收敛。

BERT的作者提出了采用MaskLM的方式来训练语言模型

通俗地说就是在输入一句话的时候，随机地选一些要预测的词，然后用一个特殊的符号来代替它们。尽管模型最终还是会看到所有位置上的输入信息，但由于需要预测的词已经被特殊符号代替，所以模型无法事先知道这些位置上是什么词，这样就可以让模型根据所给的标签去学习这些地方该填的词了。

然而这里还有一个问题，就是我们在预训练过程中所使用的这个特殊符号，在后续的任务中是不会出现的。

因此，为了和后续任务保持一致，作者按一定的比例在需要预测的词位置上输入原词或者输入某个随机的词。当然，由于一次输入的文本序列中只有部分的词被用来进行训练，因此BERT在效率上会低于普通的语言模型，作者也指出BERT的收敛需要更多的训练步数。

BERT另外一个创新是在双向语言模型的基础上额外增加了一个句子级别的连续性预测任务。这个任务的目标也很简单，就是预测输入BERT的两端文本是否为连续的文本，作者指出引入这个任务可以更好地让模型学到连续的文本片段之间的关系。在训练的时候，输入模型的第二个片段会以50%的概率从全部文本中随机选取，剩下50%的概率选取第一个片段的后续的文本。

除了模型结构，模型大小和数据量都很重要

以上的描述涵盖了BERT在模型结构和训练目标上的主要创新点，而BERT的成功还有一个很大的原因来自于模型的体量以及训练的数据量。

BERT训练数据采用了英文的开源语料BooksCropus 以及英文维基百科数据，一共有33亿个词。同时BERT模型的标准版本有1亿的参数量，与GPT持平，而BERT的大号版本有3亿多参数量，这应该是目前自然语言处理中最大的预训练模型了。

当然，这么大的模型和这么多的数据，训练的代价也是不菲的。谷歌用了16个自己的TPU集群（一共64块TPU）来训练大号版本的BERT，一共花了4天的时间。对于是否可以复现预训练，作者在 [Reddit](https://www.reddit.com/r/MachineLearning/comments/9nfqxz/r_bert_pretraining_of_deep_bidirectional)上有一个大致的回复，指出OpenAI当时训练GPT用了将近1个月的时间，而如果用同等的硬件条件来训练BERT估计需要1年的时间。不过他们会将已经训练好的模型和代码开源，方便大家训练好的模型上进行后续任务。

虽然训练的代价很大，但是这个研究还是带来了一些思考和启发。例如双向语言模型的运用，多任务对预训练的帮助以及模型深度带来的收益。相信在未来的一段时间，自然语言处理中预训练的神经网络语言模型会得到更多的关注和运用。

论文原文： https://arxiv.org/abs/1810.04805

简介

• 多线程锁定同一资源会造成死锁
• 线程池中的任务使用当前线程池也可能出现死锁
• RxJava 或 Reactor 等现代流行库也可能出现死锁

死锁是两个或多个线程互相等待对方所拥有的资源的情形。举个例子，线程 A 等待 lock1，lock1 当前由线程 B 锁住，然而线程 B 也在等待由线程 A 锁住的 lock2。最坏情况下，应用程序将无限期冻结。让我给你看个具体例子。假设这里有个  Lumberjack（伐木工） 类，包含了两个装备的锁：

import com.google.common.collect.ImmutableList;
import lombok.RequiredArgsConstructor;
import java.util.concurrent.locks.Lock;
@RequiredArgsConstructor
class Lumberjack {
    private final String name;
    private final Lock accessoryOne;
    private final Lock accessoryTwo;
    void cut(Runnable work) {
        try {
            accessoryOne.lock();
            try {
                accessoryTwo.lock();
                work.run();
            } finally {
                accessoryTwo.unlock();
            }
        } finally {
            accessoryOne.unlock();
        }
    }
}

每个  Lumberjack（伐木工）需要两件装备： helmet（安全帽） 和  chainsaw（电锯）。在他开始工作前，他必须拥有全部两件装备。我们通过如下方式创建伐木工们：

import lombok.RequiredArgsConstructor;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@RequiredArgsConstructor
class Logging {
    private final Names names;
    private final Lock helmet = new ReentrantLock();
    private final Lock chainsaw = new ReentrantLock();
    Lumberjack careful() {
        return new Lumberjack(names.getRandomName(), helmet, chainsaw);
    }
    Lumberjack yolo() {
        return new Lumberjack(names.getRandomName(), chainsaw, helmet);
    }
}

可以看到，有两种伐木工：先戴好安全帽然后再拿电锯的，另一种则相反。谨慎派（ careful()）伐木工先戴好安全帽，然后去拿电锯。狂野派伐木工（ yolo()）先拿电锯，然后找安全帽。让我们并发生成一些伐木工：

private List<Lumberjack> generate(int count, Supplier<Lumberjack> factory) {
    return IntStream
            .range(0, count)
            .mapToObj(x -> factory.get())
            .collect(toList());
}

generate()方法可以创建指定类型伐木工的集合。我们来生成一些谨慎派伐木工和狂野派伐木工。

private final Logging logging;
//...
List<Lumberjack> lumberjacks = new CopyOnWriteArrayList<>();
lumberjacks.addAll(generate(carefulLumberjacks, logging::careful));
lumberjacks.addAll(generate(yoloLumberjacks, logging::yolo));

最后，我们让这些伐木工开始工作：

IntStream
        .range(0, howManyTrees)
        .forEach(x -> {
            Lumberjack roundRobinJack = lumberjacks.get(x % lumberjacks.size());
            pool.submit(() -> {
                log.debug("{} cuts down tree, {} left", roundRobinJack, latch.getCount());
                roundRobinJack.cut(/* ... */);
            });
        });

这个循环让所有伐木工一个接一个（轮询方式）去砍树。实质上，我们向线程池（ ExecutorService）提交了和树木数量（ howManyTrees）相同个数的任务，并使用  CountDownLatch 来记录工作是否完成。

CountDownLatch latch = new CountDownLatch(howManyTrees);
IntStream
        .range(0, howManyTrees)
        .forEach(x -> {
            pool.submit(() -> {
                //...
                roundRobinJack.cut(latch::countDown);
            });
        });
if (!latch.await(10, TimeUnit.SECONDS)) {
    throw new TimeoutException("Cutting forest for too long");
}

其实想法很简单。我们让多个伐木工（ Lumberjacks）通过多线程方式去竞争一个安全帽和一把电锯。完整代码如下：

import lombok.RequiredArgsConstructor;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;
import java.util.function.Supplier;
import java.util.stream.Collectors;
import java.util.stream.IntStream;
@RequiredArgsConstructor
class Forest implements AutoCloseable {
    private static final Logger log = LoggerFactory.getLogger(Forest.class);
    private final ExecutorService pool;
    private final Logging logging;
    void cutTrees(int howManyTrees, int carefulLumberjacks, int yoloLumberjacks) throws InterruptedException, TimeoutException {
        CountDownLatch latch = new CountDownLatch(howManyTrees);
        List<Lumberjack> lumberjacks = new ArrayList<>();
        lumberjacks.addAll(generate(carefulLumberjacks, logging::careful));
        lumberjacks.addAll(generate(yoloLumberjacks, logging::yolo));
        IntStream
                .range(0, howManyTrees)
                .forEach(x -> {
                    Lumberjack roundRobinJack = lumberjacks.get(x % lumberjacks.size());
                    pool.submit(() -> {
                        log.debug("{} cuts down tree, {} left", roundRobinJack, latch.getCount());
                        roundRobinJack.cut(latch::countDown);
                    });
                });
        if (!latch.await(10, TimeUnit.SECONDS)) {
            throw new TimeoutException("Cutting forest for too long");
        }
        log.debug("Cut all trees");
    }
    private List<Lumberjack> generate(int count, Supplier<Lumberjack> factory) {
        return IntStream
                .range(0, count)
                .mapToObj(x -> factory.get())
                .collect(Collectors.toList());
    }
    @Override
    public void close() {
        pool.shutdownNow();
    }
}

现在，让我们来看有趣的部分。如果我们只创建谨慎派伐木工（ careful Lumberjacks），应用程序几乎瞬间运行完成，举个例子：

ExecutorService pool = Executors.newFixedThreadPool(10);
Logging logging = new Logging(new Names());
try (Forest forest = new Forest(pool, logging)) {
    forest.cutTrees(10000, 10, 0);
} catch (TimeoutException e) {
    log.warn("Working for too long", e);
}

但是，如果你对伐木工（ Lumberjacks）的数量做些修改，比如，10 个谨慎派（ careful）伐木工和 1 个狂野派（ yolo）伐木工，系统就会经常运行失败。怎么回事？谨慎派（ careful）团队里每个人都首先尝试获取安全帽。如果其中一个伐木工取到了安全帽，其他人会等待。然后那个幸运儿肯定能拿到电锯。原因就是其他人在等待安全帽，还没到获取电锯的阶段。目前为止很完美。但是如果团队里有一个狂野派（ yolo）伐木工呢？当所有人竞争安全帽时，他偷偷把电锯拿走了。这就出现问题了。某个谨慎派（ careful）伐木工牢牢握着安全帽，但他拿不到电锯，因为被其他某人拿走了。更糟糕的是电锯所有者（那个狂野派伐木工）在拿到安全帽之前不会放弃电锯。这里并没有一个超时设定。那个谨慎派（ careful）伐木工拿着安全帽无限等待电锯，那个狂野派（ yolo）伐木工因为拿不到安全帽也将永远发呆，这就是死锁。

如果所有伐木工都是狂野派（ yolo）会怎样，也就是说，所有人都首先去尝试拿电锯会怎样？事实证明避免死锁最简单的方式就是以相同的顺序获取和释放各个锁，也就是说，你可以对你的资源按照某个标准来排序。如果一个线程先获取 A 锁，然后是 B 锁，但第二个线程先获取 B 锁，会引发死锁。

线程池自己引发的死锁

这里有个与上面不同的死锁例子，它证明了单个线程池使用不当时也会引发死锁。假设你有一个  ExecutorService，和之前一样，按照下面的方式运行。

ExecutorService pool = Executors.newFixedThreadPool(10);
pool.submit(() -> {
    try {
        log.info("First");
        pool.submit(() -> log.info("Second")).get();
        log.info("Third");
    } catch (InterruptedException | ExecutionException e) {
        log.error("Error", e);
    }
});

看起来没什么问题 —— 所有信息按照预期的样子呈现在屏幕上：

INFO [pool-1-thread-1]: First
INFO [pool-1-thread-2]: Second
INFO [pool-1-thread-1]: Third

注意我们用  get() 阻塞线程，在显示“ Third”之前必须等待内部线程（ Runnable）运行完成。这是个大坑！等待内部任务完成意味着需要从线程池额外获取一个线程来执行任务。然而，我们已经使用到了一个线程，所以内部任务在获取到第二个线程前将一直阻塞。当前我们的线程池足够大，运行没问题。让我们稍微改变一下代码，将线程池缩减到只有一个线程，另外关键的一点是我们移除  get() 方法：

ExecutorService pool = Executors.newSingleThreadExecutor();
pool.submit(() -> {
    log.info("First");
    pool.submit(() -> log.info("Second"));
    log.info("Third");
});

代码正常运行，只是有些乱：

INFO [pool-1-thread-1]: First
INFO [pool-1-thread-1]: Third
INFO [pool-1-thread-1]: Second

两点需要注意：

• 所有代码运行在单个线程上（毫无疑问）
• “Third”信息显示在“Second”之前

顺序的改变完全在预料之内，没有涉及线程间的竞态条件（事实上我们只有一个线程）。仔细分析一下发生了什么：我们向线程池提交了一个新任务（打印“ Second”的任务），但这次我们不需要等待这个任务完成。因为线程池中唯一的线程被打印“ First”和“ Third”的任务占用，所以这个外层任务继续执行，并打印“ Third”。当这个任务完成时，将单个线程释放回线程池，内部任务最终开始执行，并打印“ Second”。那么死锁在哪里？来试试在内部任务里加上  get() 方法：

ExecutorService pool = Executors.newSingleThreadExecutor();
pool.submit(() -> {
    try {
        log.info("First");
        pool.submit(() -> log.info("Second")).get();
        log.info("Third");
    } catch (InterruptedException | ExecutionException e) {
        log.error("Error", e);
    }
});

死锁出现了！我们来一步一步分析：

• 打印“First”的任务被提交到只有一个线程的线程池
• 任务开始执行并打印“First”
• 我们向线程池提交了一个内部任务，来打印“Second”
• 内部任务进入等待任务队列。没有可用线程因为唯一的线程正在被占用
• 我们阻塞住并等待内部任务执行结果。不幸的是，我们等待内部任务的同时也在占用着唯一的可用线程
• get() 方法无限等待，无法获取线程
• 死锁

这是否意味单线程的线程池是不好的？并不是，相同的问题会在任意大小的线程池中出现，只不过是在高负载情况下才会出现，这维护起来更加困难。你在技术层面上可以使用一个无界线程池，但这样太糟糕了。

Reactor/RxJava

请注意，这类问题也会出现在上层库，比如  Reactor：

Scheduler pool = Schedulers.fromExecutor(Executors.newFixedThreadPool(10));
Mono
    .fromRunnable(() -> {
        log.info("First");
        Mono
                .fromRunnable(() -> log.info("Second"))
                .subscribeOn(pool)
                .block();  //VERY, VERY BAD!
        log.info("Third");
    })
    .subscribeOn(pool);

当你部署代码，它似乎可以正常工作，但很不符合编程习惯。根源的问题是相通的，最后一行的  subscribeOn() 表示外层任务（ Runnable）请求了线程池( pool)中一个线程，同时，内部任务（ Runnable）也试图获取一个线程。如果把基础的线程池换成只包含单个线程的线程池，会发生死锁。对于 RxJava/Reactor 来说，解决方案很简单——用异步操作替代阻塞操作。

Mono
    .fromRunnable(() -> {
        log.info("First");
        log.info("Third");
    })
    .then(Mono
            .fromRunnable(() -> log.info("Second"))
            .subscribeOn(pool))
    .subscribeOn(pool)

防患于未然

并没有彻底避免死锁的方法。试图解决问题的技术手段往往会带来死锁风险，比如共享资源和排它锁。如果无法根治死锁（或死锁并不明显，比如使用线程池），还是试着保证代码质量、监控线程池和避免无限阻塞。我很难想象你情愿无限等待程序运行完成，如同  get() 方法和  block() 方法在没有设定超时时间的情况下执行。

感谢阅读！

相关文章

• 如何通过编程发现Java死锁
• Java死锁范例以及如何分析死锁
• Java 线程池详解
• Java面试：投行的15个多线程和并发面试题
• 深入学习 Java 线程池
• Java 多线程编程 — 锁优化
• 源码 | 批量执行invokeAll() && 多选一invokeAny()
• 聊一聊 Spring 中的线程安全性
• 条件队列大法好 ：wait 和 notify 的基本语义
• MySQL 死锁与日志二三事

<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.springframework.org/schema/beans
                    http://www.springframework.org/schema/beans/spring-beans-4.2.xsd"
default-autowire="byName"><bean id="commonDataSource" class="org.apache.commons.dbcp2.BasicDataSource"><property name="driverClassName" value="com.mysql.jdbc.ReplicationDriver"></property><property name="url" value="jdbc:mysql:replication://127.0.0.1:3306,127.0.0.1:4306,127.0.0.1:5306/mydb?useUnicode=true&amp;characterEncoding=UTF-8&amp;autoReconnect=false&amp;useSSL=false&amp;failOverReadOnly=true&amp;loadBalanceStrategy=random&amp;readFormMasterNoSlaves=true"></property><property name="username" value="test"></property><property name="password" value="test"></property><property name="maxTotal" value="12"></property><property name="maxIdle" value="2"></property><property name="minIdle" value="2"></property><property name="maxWaitMillis" value="30000"></property><property name="defaultAutoCommit" value="true"></property><property name="defaultReadOnly" value="true"></property><!-- 必须为false，否则@transactional中的readOnly将无法正常工作 --></bean><bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean"><property name="dataSource" ref="commonDataSource" /><property name="configLocation" value="classpath:sqlmap-config.xml"></property><!-- <property name="dataSource" ref="dataSource" /> --></bean><bean name="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"><property name="dataSource" ref="commonDataSource"/></bean><bean name="transactionTemplate" class="org.springframework.transaction.support.TransactionTemplate"><property name="transactionManager" ref="transactionManager" /><property name="isolationLevelName" value="ISOLATION_READ_COMMITTED"/><property name="timeout" value="30"/></bean><!-- core api，必须为prototype --><bean id="sqlSessionTemplate" class="org.mybatis.spring.SqlSessionTemplate" scope="prototype"><constructor-arg index="0" ref="sqlSessionFactory" /></bean><!-- 非常重要,否则@transactional将无法生效 --><tx:annotation-driven proxy-target-class="true" transaction-manager="transactionManager"/></beans>

@Component
public class TestDaoImpl extends BaseDao implements TestDao {

    @Override
    public TestDO get(int id) {
        return this.sqlSessionTemplate.selectOne("TestMapper.get",id);
    }

    @Override
    @Transactional(readOnly = false)
    public void update(TestDO test) {
        this.sqlSessionTemplate.update("TestMapper.update",test);
    }

}

@Component
public class TestManagerImpl implements TestManager {

    @Autowired
    private TestDao testDao;

    @Autowired
    private Test2Dao test2Dao

    @Override
    public TestDO get(int id) {
        return this.testDao.get(id);
    }
 
    @Override
    @Transactional(readOnly = false)
    public void update(TestDO test) {
        this.testDao.update(test);
        this.test2Dao.insert(test);//事务中执行
    }

}

• —软件人才免语言低担保 赴美带薪读研！—

360周鸿祎：IOT时代的信息安全 六挑战三原则

    前一段时间我干了很多和安全关系不大的事情，看到了很多传统行业的老大如何患上“互联网焦虑症”，他们害怕互联网成为传统价值的毁灭者，其实这些是对于互联网的一些误解，所以我还写了一本书，讲我的互联网方法论。

很多人问我互联网思维是什么？如果用一个词总结是什么？我想了想是在过去的20年里互联网最大的力量就是实现了“网聚人的力量”，互联网把我们很多人连接起来。

在互联网第一代的时候是PC互联网，我们每个人的电脑连接起来，这时候安全问题还OK，当时的防病毒和查杀流氓软件，以及我们很多边界和防火墙的防御技术；但到了互联网的新阶段，我们每个人都用手机了，今天手机已经变成我们每个人手上的一个器官，我们每个人有一种新的病，几分钟不看手机就觉得心里很失落，手机变成了一个新的连接点。手机打破了我们原来对边界的定义，手机更多和我们的个人隐私信息联接在一起，所以，安全的问题变得更加严重。

有一个好消息，也是一个坏消息，手机互联网之后，下一个五到十年我们的互联网将会往何处去？

其实我觉得一个最重要的时代可能要开始那就是IoT——Internet of Things，万物互联。

美国的硅谷现在非常流行IoT这个词，Internet of Things，我早些时候提出来有些人质疑是“物联网”的翻版，但是我认为并不是。物联网被翻译成传感器网络，而IoT网络是万物互联的。

    来IoT时代，所有设备都将内置一个智能芯片和智能OS，所有设备都能通过各种网络协议进行通信，而且是7 x 24小时的相连，能够产生真正海量的大数据；并且，伴随大数据应用的逐步升级，也会让机器变得更加智能，甚至具备自己的意识。我认为，IOT时代的信息安全其实也是大数据的安全问题，而且至少要面临六方面的挑战。

首先，当所有的设备都变成智能化，都接入网络以后，边界的概念将会进一步被削弱，也就是说接入点越多，可以被攻破的这种可能的入口就会越多。过去，我们很信奉“隔离”、“切断”，我们可以把电脑放在一个屋子里，我们可以把一个网络进行隔离，但今天你会发现越来越多的不起眼设备都支持Wi-Fi和蓝牙，这里面有太多可以被别人攻击的接入点，而且攻击点越多，对防守的挑战就会越大。

第二，未来企业都将成为互联网企业，企业信息安全面临更大的挑战。过去我们很多企业可能不太重视企业的安全，我们很多时候买防火墙是为了合规，是上级要求和行业要求。过去我们企业的发展，可能把自己割裂在一个安全的孤岛上，但你要变成互联网企业之后，你不可避免要把自己的核心业务系统接入到互联网上。

但当所有的企业都变成互联网企业之后，企业安全一定要提高到一个更重要的优先级上，也就是说当你的服务器或你的网络被攻破之后，可能不意味着仅仅是你内部数据的泄露，可能意味着用户数据的灾难。

第三个问题，大数据污染。就是大数据中如果被人为加入了各种无效、错误的数据，人为操作和注入修改虚假信息，在数据传输存储过程中出现了问题，那么根据大数据所做的一切行业指导和趋势分析，都可能面临灾难性的后果。

第四，智能设备IoT被控制之后的灾难，这种危害或者会比电脑手机更大。

    过去大家都记得，你的电脑中毒了、有问题了，大家最多觉得“今天给老板交的报告写不出来了”，所以我电脑中毒了经常成为工作完不成的一个借口。机出问题了呢，无非你们看到最近多了很多“艳照”，不小心照片上传了；然今天手机和支付系统连在一起，可能当你的通信录被盗用了，就会收到一些诈骗短信。包括前面讲到的那个木马之所以会得逞，就是因为它盗用了你的通信录的地址本，熟人发来的短信，大家都会连接。

    但IoT是可被控制的，不是一个单纯的网络，这个被控制了带来的风险就大了。

    前段时间中国人崇拜完乔布斯之后，因为中国的假乔布斯太多了，他们又开始崇拜美国另外一个人，号称钢铁侠，他造了一部汽车叫做特斯拉，他上次来中国的时候，我有幸和他们大家一起吃了晚餐。我问了一个他很恼怒的问题，我说你的汽车会被人骇客吗？他说不会，我们所有的应用都是自己写的，我们不会安装任何第三方应用，所以不会有任何问题。我就提了两个问题，第一个你的汽车是有Wi-Fi和蓝牙，我可能骇客不了你的汽车，但你用手机接入的话，我可以骇客你的手机，我一样可以通过手机骇客这个汽车。自然你是一个智能汽车，它就像一个大手机一样，一定要和云端通信，所以如果有人下发了你的通信协议或者破解了你的云端的网络，我一样可以控制你的汽车。

    我们后来在全国征得了很多有识之士，有人成功破解了对特斯拉的协议，成功实现了对汽车的控制。所以，中国汽车厂要生产智能汽车，我给他们说最重要的不是边开汽车边看互联网影视，最重要的是老百姓敢不敢开你的车，如果半路上突然死机了，突然蓝屏了，突然弹出一个大窗口说你必须下载一个什么玩意儿，这样的汽车不会有人开的，一旦出现问题就会非常的严重。

第五个问题，当大数据产生了人工智能之后，很可能人类技术发展会到达一个新的“奇点”。

    比如说以后的机器人和智能汽车，我有一个断言，它未必是由这个设备里的智能系统单独做智能判断，它一定是和云端一个更大的智能系统相连。

    比如真正的智能驾驶，你何止需要这一部汽车的数据才能做判断，可能需要路边很多传感器和很多其他汽车发来的信息，你需要在云端进行高速的分析，再反馈过去。所以，将来有一天可能不仅仅是这台车上的电脑在指挥，很有可能是云端的一个机器在指挥。

    因此，各种各样无论是专用机器人还是通用机器人，在几年以后也会越来越普及，都会和互联网相连，甚至它们再反过来对各种设备进行反向控制。

    这样，当真正云端安全出现问题以后，机器智能带来的转换，这是我们下一个五到十年必须要考虑的问题。

第六个问题，也是最重要的一个挑战就是对用户隐私的挑战。

    如果说IOT时代，各种传感器让每个人的数据维度更加丰富了，而且产生的数据都记录在云端，所以IOT时代的大数据下每个人都是透明的，一旦出现泄露后果也是极其严重的。

    而且值得深思的是，在对用户隐私信息的保护，现行的法律和规则的制定都是落后的，有很多问题是不清楚的，怎样在这种情况下更好的去保护我们个人的隐私？除非不用任何先进设备、不接入网络，否则用户的个人隐私信息永远都是安全挑战。

    就像前几天我看到美国有一家公司，只要给他的试管吐一口吐沫，就可以免费测出用户的基因组。未来基因的检测的成本会更低，而这样的公司他直接拿到了用户的最隐秘数据——基因。

       所以说，IOT时代可以是某些企业的黄金时代，但同样对信息安全的保护却变得无比脆弱。对于这六个方面的挑战，有些已经在发生，有些是即将发生。在此， 我也提出一个新的想法，在大数据时代，如何保护用户信息的三原则。

第一，数据应该是用户的资产，这是必须明确的。虽然未来将有大量的信息存在互联网服务商的服务器上，但是用户数据的所有权必须明确，所有数据与信息都是属于用户的个人资产。

第二，任何企业都需要把收集到的用户数据进行安全存储和安全的传输，这是企业的责任和义务。

不仅仅是提供互联网服务的公司，包括所有暂时存储着用户数据的想做互联网业务的公司，都要提高公司安全能力，都要有加强安全防护水平的责任和义务；既然你们要收集用户数据，就必须解决传输、存储的基本安全问题。

第三，用户信息的使用，一定要保障用户的知情权和选择权，平等交换、授权使用。

存有用户数据的企业，在使用这些数据之前，一定要遵循平等交换，授权使用的原则，不能未经许可采集和滥用。更重要的是，要保障用户说“不”的权力：还有很多用户可以选择，当不需要某项服务时，可以把它关掉，可以拒绝采集数据，用户一定要有这种选择权。

    不论是现在，还是未来，这些数据在未经用户授权的情况下进行了交易牟利，这不仅要被视作不道德的行为，更应该视为是非法的。

    所以有了这三原则，在我们进入IoT时代时，我们才能让用户对下一代互联网感觉更放心，才能更好的使用。

    只有安全的互联网才有美好的互联网，所以在互联网上最重要的就是安全第一。

10 月 23 日机器之心消息，依图科技推出智慧园区端到端解决方案，全系列均为自研方式，产品方案包括「云悉明眸」智慧管理平台、智能人脸识别门禁终端、智能人脸识别闸机版终端、智能人脸抓拍摄像机系列等数款基于人脸识别的产品，面向智慧园区、智能楼宇等建筑类场景。据悉，这是依图首次通过端到端的产品解决方案切入智慧园区市场。

依图科技智慧园区营销总监陈静锋现场介绍业务布局

针对依图此次发布的产品内容与智慧园区市场战略，机器之心与依图智慧园区产品线负责人进行交流。

系统层面，「云悉明眸」园区智慧管理平台以「决策模组」为核心，能够实现系统级的主动安防、人员准入及运营分析等任务，满足用户在系统层面上的数据汇总、物物互联的需求。

在园区管理中，以人脸为 ID，规避被冒充的风险，保证了 ID 的唯一性。结合依图在人像识别领域的技术优势，以推动智慧园区的管理升级。

「目前整套系统已经实现跟传统的监控系统、门禁系统无缝集成，同时通过标准接口与园区既有运营大平台实现融合。」依图方面介绍道。

依图智慧园区业务线负责人向机器之心表示，智慧园区市场正在呈现高速增长的趋势，AI 产品覆盖智慧园区市场的规模 2018 年预计在 20 亿元以上。

方案整体采用开放式架构，支持公有云和私有云，从架构上覆盖最多的园区、建筑类场景要求。同时，通过人脸识别这一技术手段，增加安防维度，「洞察」更多潜在危险、「发现」那些需要关注的人群，方便用户获得更好的服务。

比如：充分利用依图人脸识别技术的高速、精准的特点，实现「无感考勤」；帮助安保人员及时处理园区异常人员情况，进行「黑名单报警」；以人像为主轴，通过时间、空间碰撞，串联起不同人在园区内行为路线的「人员轨迹地图」，帮助园区实现进一步的主动安防或主动服务。

依图方面表示，团队很早就开始研究智慧园区的需求和发展，从最早期的数字园区，完成从模拟到网络化的转变；从数字到智能，完成系统间数据互联的基本定义与集成；如今园区已经进入智慧化时代，更多的是通过物物联网，实现大数据集成，通过多维度的数据汇集与分析，更好的为用户服务。

谈到智慧园区升级后将带来的经济价值，依图智慧园区产品线负责人向机器之心据介绍，传统的智慧园区主要采用空间、时间维度提供数据，而基于 AI 的智慧园区方案，我们提供精准的、实时的人像身份数据，提高了数据维度。更重要的是，方案将人的身份识别作为第一维度，即当任何人进去园区，客户就能迅速判断人员身份，从而进行进一步的主动安防或主动服务的工作，这个是传统园区方案无法比拟的。

对于智慧园区场景下的数据价值，依图方面表示，基于人像数据，原本被动的园区管理、园区安防体系将会更为主动，能够让园区运营者将「时间、地点、人物」在第一时间串接起来，真正形成数据链条，园区拿着这些数据可以实现园区运营状况实时分析、流量精准分析、VIP 客户个性化服务等；同时长期的数据汇聚和分析，有利于园区调整自身营运结构、根据不同的人采取不同的策略，这些策略是通过大量的身份管理数据基础上总结获得的。

事实上，依图智慧园区的系列解决方案在今年早些时候已经成功产品化落地。在活动现场，依图科技分别展示了在上海市世界外国语小学、太平洋资产管理有限公司、上海宝地广场、中建八局等应用案例。

在上海宝地广场项目中，依图科技落地的智慧楼宇解决方案包括智能刷脸进出、智能访客登记、智能安全防控等能力。上海宝地仲量联行物业服务有限公司总经理金立新在接受采访时说：「物业管理是劳动密集型行业，每年人力成本的支出占到 70% 以上。人工智能引入后，从安保、清洁到执行、管理，人力成本都将大大节约，带来巨大效益。」

在上海世界外国语小学项目中，依图的产品和技术除了在通行管理、教职工考勤、校园安保方面「执勤」外，未来还将扩展到校车管理，学生上车识别、位置、时间数据汇聚推送；校园餐厅管理，学生教职工刷脸就餐；公安联动，共建平安校园等方方面面。

此外，方案还包括智能抓拍摄像头、智能人脸识别闸机版等终端产品。依图方面表示，其产品逻辑在于整个系统是以人为轴，从人的动线考虑。在平面空间维度，用门禁和闸机伴侣在通道口、大门针对管理人员的进出；在立体空间层面，用摄像头从上至下监控整个空间的动态。同时，将动态数据传送至后端平台，提供端到端整体解决方案。

据机器之心了解，这是依图首次通过端到端的产品线切入泛安防领域的智慧园区市场，同时也是以 AI 能力为强项的技术公司少有的产品模式。因为安防市场本质仍是一块相对传统和成熟的 B 端市场，从已经成型的硬件设备市场直接切入可能面临来自传统公司的大量竞争。

我们面临的竞争是非常激烈的，依图智慧园区产品线负责人向机器之心表示，不仅传统传统的安防厂商，新的 AI 厂商都在智能终端这块发力。但是依图凭借领先的算法，警转民的高安全技术、数据加密技术等，相信可以在市场上杀出一条属于依图的成功之路。

面向智能抓拍摄像头市场，依图推出了 200 万像素的枪型、半球型两款产品，抓拍准确率保证在 99%。与后端的应用结合可完成布控、查看人员轨迹、签到等功能。其中，半球型摄像机整体比较小，可以用在对美观度要求比较高的场景，比如办公室，酒店，商场等场景。枪型摄像机可以搭配室外护罩在纯室外条件下使用，更适用于园区，楼宇边界的布控。

200万像素智能人脸抓拍半球网络摄像机

相较于普通安防摄像头，智能抓拍摄像头最大的优势在于功能前置，将算法直接嵌入在前端，从人脸的捕获，抓拍，到图片质量优选，前端可直接输出最好的抓拍结果给后端，节省后端的算力，降低用户总体成本。

目前，智能摄像机采用依图自研前端捕获算法，提供适合人脸识别场景的优化性能，配合后端世界级的算法平台，实现端到端的，最精准及快速的识别体验。此外，依图还兼容对其他品牌的抓拍摄像机单元，节省用户侧投资。

依图科技业务发展副总裁程刚

依图科技业务发展副总裁程刚表示，对于跟用户的自身业务密切相关，难以标准化的需求，依图还将与众多合作伙伴一起行动，建立新的产品机制，基于平台全维度的接口，通过建立产品体系生态圈政策，解决客户最后「50 米」的需求。

除了此次推出的智慧园区解决方案，依图针对泛安防市场已经完成的布局还包括商业楼宇的解决方案、工业园区解决方案以及校园解决方案等多个解决方案，目标市场包括金融园区、酒店、文旅景区等。

依图方面表示，此前依图从智能城市的安防建设构建城市公共区域的防护网，现在依图开始进入园区市场，形成园区方案，这样无论是城市公共区域、还是封闭性的园区，依图真正意义地提供了「城市级」的解决方案。依图智慧园区产品线负责人透露，端到端的产品将会依图未来的方向之一。

从依图的整体业务布局来看，主要包括智能安防、智能医疗、智慧金融、智慧城市、智能硬件等五大业务板块。其中此次推出的智慧园区方案属于智能安防（泛安防）业务板块，其主要突破口在于智能硬件及其系统解决方案。

据公开消息显示，依图最近一轮融资结束于今年 6 月，C+轮 3 亿美金，投资方包括高成资本、工银国际、浦银国际投资。

面向智慧园区解决方案市场，除了海康威视、大华、宇视等传统安防巨头布局，芯片公司比特大陆等也在近期推出了相关方案。