（预计阅读时间：6分钟）
最近，TuGraph团队开展了一项令人振奋的优化工作，成功将Antlr4 C++ target的并发性能提升超过10倍！这一优化方案已被Antlr4开源社区热情接纳，将给全球的Antlr C++生态开发者带来更好的使用体验。PR地址：
https://github.com/antlr/antlr4/pull/4237
图查询引擎是一种用于查询图数据库的工具，它使用特定的查询语言（如Cypher或ISO GQL）来执行和操作图数据库。这些查询语言允许用户描述图模式并查询图数据，例如查找特定节点或查找节点之间的路径。
关于Antlr4
Antlr4是一款备受欢迎的开源解析器生成器，能够根据语法规则快速生成自定义解析器。其支持LL(*)解析，拥有更强大的错误处理能力和更快的解析速度。不仅如此，Antlr4还支持Java、Python、C++、JavaScript、Go等10种目标语言，广泛应用于多种开发语言生态中。简单易用的API和文档使得开发人员能够快速上手。无论是编程语言、数据格式、编译器还是解释器等领域，Antlr4都发挥着重要作用。
著名的开源项目如Apache Spark、Eclipse IDE和MongoDB等都选择了Antlr4。对于语言工具开发者而言，Antlr4是不可或缺的工具，能大幅提高开发效率和代码质量。
当TuGraph遇见Antlr4
ISO GQL（ISO/IEC 39075）是一种标准化的图数据库查询语言，蚂蚁集团是其主要贡献者之一。因此，Antlr4作为一种强大的解析器生成器，成为了蚂蚁图数据库TuGraph生成GQL解释器的理想选择。Antlr4能够帮助团队更快、更准确地构建图数据库的查询语言，从而提高产品性能和用户体验。
然而，当我们从开发场景来到生产场景，超高的并发量带来一个严重问题：Antlr4 C++ target的并发性能不足以支持所需的超高并发GQL请求。经过调研并与Antlr开源社区讨论，我们发现并发性能这个问题普遍存在，并且在过去5年中持续困扰着C++生态的开发者。我们决定解决这个问题。
我们做了哪些工作
在调研讨论的过程中我们发现，多位开发者在论坛提出其耗时甚至多于Java target数倍之多，见文末参考【1，2，3，4】。因此，我们决定从问题和开源代码出发，来定位、解决问题。
这是一个典型的并发程序优化问题，根据以往的程序优化经验，我们分步推进该问题的解决：
（1）识别问题
通过对程序运行时的性能数据进行收集和分析，我们找到了程序运行瓶颈所在，通过调用分析，初步将问题定位为数据竞争导致的并发问题。
（2）深入阅读Antlr4开源代码
接下来，我们对Antlr4的源代码进行仔细的阅读和理解，掌握其内部的结构和核心逻辑，找出了核心的数据结构和关键的调用链路。为我们破解性能难题和分析修改的正确性做好了准备。
（3）梳理数据竞争链路
根据上述分析，我们判断问题的症结极大概率是数据竞争造成的。形成数据竞争至少有两个条件：一是线程之间共享内存数据，二是至少存在两个线程去读写某个共享内存。
进一步地，我们通过分析程序中的并发访问情况，找到了可能引发数据竞争的所有代码段和共享变量（主要为DFA、ATN等结构），拼接出了数据竞争的完整链路。
（4）破解数据竞争问题
数据竞争问题是多线程程序中常见而又复杂的问题，可以考虑通过破解多种竞争条件来解决。就本文问题来说，也存在多种破解方案选择，如何制定最优的解决方案是一项极具挑战的工作，主要难点有两个：
（i）保证修改后程序的正确性/稳定性
（ii）保证方案的有效性（低成本）
反复推演后，我们选择了提交给社区的优化方案（PR地址见参考【6】），即通过改变关键数据的ownership接触对锁的依赖。针对上述两个难点的分析如下：
经过源码分析并与开源社区讨论，我们确认关键数据结构的初始化构建是非常耗时的，但可以通过“只调用一次”（\`call_once\`）手段将成本均摊，而后续的增量构建相对开销较低，并且也可均摊。因此该优化方案的低时间成本是可以保证的。
关于程序正确性的保证，我们通过双重验证来保证。首先在设计之初我们已经从源代码角度，推断出共享数据仍然是安全的，其次我们也设计了实验对此进行了验证，验证结果与我们的分析一致（见下图）。
贡献和成果
优化的效果十分显著，32线程的并发性能提升超过18倍，如下图所示（16核心CPU测试平台，性能测试代码仓库见【5】）。考虑到实际生产服务器性能远高于测试机型，实际的性能提升效果将比测试结果更高，优化后GQL解析能力已能完全满足企业业务的需要。
充满收获的社区互动
提案的互动过程曲折也充满乐趣。当涉及到多线程代码的修改时，官方开发团队会格外谨慎，因为这涉及到系统的稳定性和性能。他们会进行仔细的测试和评估，确保修改不会引入新的问题或降低系统的性能。为此社区引入了多达7名评审专家（一般提案的评审人多为1~2人），长达60多次的反复讨论不仅是评审专家理解提案的过程，也让我们了解了很多Antlr4代码背后深层的设计理念，可以更好地利用它来构建高性能、可维护的语法分析器。
通过此项优化工作，我们收获了更多与其他社区贡献者协作的经验，多位Antlr4社区成员也对TuGraph团队的工作表达了感谢，Antlr4负责人评价该提案为“一个重大的贡献”（a major contribution）。
参考文献
【1】antlr4 doesn't scale on a computer with 8 or more cores, https://github.com/antlr/antlr4/issues/2454
【2】Parsing with C++ target 5x slower than Java, https://github.com/antlr/antlr4/issues/2584
【3】Performance Issues Running Cpp Runtime on Many Threads, https://github.com/antlr/antlr4/issues/3938
【4】Why the C++ target is 6X slower than the Java target, https://stackoverflow.com/questions/52528982/why-the-c-target-is-6x-slower-than-the-java-target
【5】The test repo: https://github.com/wangtao9/antlr4-perfopt-test
【6】Optimize the concurrent performance of Cpp target by more than 10 times, https://github.com/antlr/antlr4/pull/4237
欢迎关注TuGraph！
https://github.com/tugraph-family
END
往期回顾
→ TuGraph阿里云免费试用、技术正文，更有丰富互动奖品
→ 蚂蚁集团开源图数据库TuGraph，成立图计算开源委员会
▼ 关注蚂蚁图计算，了解最新资讯