线上使用Node.js技术作为中间层，进行前后端彻底的分离的方案现在越来越广泛地应用到企业开发中。这也是在容器化微服务架构趋势下“服务端设计的接口究竟是面向UI还是只是通用服务？”这个命题中许多企业选择的答案。

而在这种选择下，开发者普遍遇到的问题是：一方面工程师们享受Node.js带来的更高自由度的前后端分离方案，更好的渲染性能，更便捷的接口组装和数据处理；另一方面Node.js应用对于绝大多数开发者来说却处于一个黑盒状态，导致应用稳定性没有保障。结合为客户排查一些线上故障和之前我自己的编写业务框架和业务开发的工作经历，内存泄漏的问题是使用Node.js进行服务端开发时经常遇到的一颗炸弹。

武侠小说里常常写到：天下武功，唯快不破。那么当我们在业务上线后通过一些通用的监控基础设施发现线上的Node服务存在内存泄漏时，也肯定是希望能最快地定位并解决问题，以对用户的影响降到最低。所以本次分享将从Node.js内嵌的v8引擎提供的垃圾回收原理，以及遇到的一些真实且典型的内存泄漏代码案例排查分析总结，来帮助大家应对线上遇到的内存泄漏，更理想的是能帮助大家在开发阶段避免写出内存泄漏的代码。

主要内容

1. 新生代、老生代的gc原理，增量式标记；
2. Heapsnapshot是什么，怎么获取，以及Heapsnapshot的内容详解；
3. EventHandle——经常被忽略的泄漏；
4. 网红Vue/React——SSR时记得注意这些；
5. co递归、logger对象实例无限制和graphql使用不当引发的典型内存泄漏案例深度分析；
6. 一些总结。

开发者越来越关注异步编程。现代软件系统都互相连接，保持通信。很多编程语言都加入了某种形式的异步支持，如async/await。不过Kotlin用协程（coroutine）新颖地解决了这个问题。

我们一起看看基于futures/promises的传统async/await方式存在的问题，解释Kotlin基于coroutine和continuation概念提供的解决方案，从而了解为什么说Kotlin的编程模型更安全、更容易。

Asynchronous programming is on the rise. Modern software systems are connected and constantly communicating. Programming languages are adding some form of asynchronous programming like async/await. However, Kotlin had taken a fresh approach to this problem with Kotlin Coroutines.

In this talk, we’ll study various approaches to asynchronous programming, their evolution, differences and similarities. We’ll see the problem with the traditional async/await approach that is based on futures/promises and how the Kotlin’s solution that is based on concepts of coroutines and continuations is giving us safer and easier programming model.

Go语言的协程并发机制，使得Go非常适用于大规模高并发后端服务器程序开发。越来越多的开发团队开始用Go开发自己的系统，大量的开发人员开始迁移到Go语言。由于大量的后台开发人员都是从Java/C/C++迁移到Go，其中的并发编程机制存在着一定差异，常常会由于惯性思维导致一些低效和错误的实现，而并没有真正发挥Go语言的并发优势。

本讲座针对那些从传统语言迁移至Go的开发人员，比较了Go语言及传统服务器开发语言的并发编程模式，指出了沿用传统思维易导致的复杂性和错误，以及如何利用Go的并发编程新特性更加简单和高效地实现常见的并发场景。

C#一直在稳健演进，不断引入新的特性，提升在各方面的表达能力。我想C#有些特性是走在前面的。在本次演进中，我将以几个具体案例，比如如何应对Null，如何处理异步流的回调地狱问题，阐述C#解决问题的思想。

演进并不需要你有C#背景。不管你喜欢何种编程语言，希望我分享的问题解决思路对你有所帮助。

概率编程是一种系统创建方法，它所创建的系统能够帮助我们在面对不确定性时做出决策。许多日常决策涉及在确定无法直接观测的相关因素时的判断能力。本次演进将结合具体案例详细介绍概率编程的思想与应用。

iOS发展已经超过十年的时间，已经成长成为一个成熟的软件平台。这意味着绝大多数的iOS项目的迭代时间已经超过了3年，伴随着的不断膨胀的代码，还有各种各样的历史包袱。最严重就是大量的状态、中间层导致迭代新功能所需要的成本越来越高。

本次分享会结合Swift的函数式特性以及FRP的思想，尝试对传统的观察者模式（Listener/Delegate/Callback）和状态机（State Machine）进行改进，来实现更好的状态管理，更可控的回调时序以及更安全、鲁棒的编程模式，解放程序员在维护大型复杂项目的心智负担。

听众受益

• Swift的函数式特性以及函数响应式编程思想；
• 使用响应式的Signal来建模事件（Event）和状态（State）；
• 将可变数据（mutable data）/异步任务/IO网络封装为immutable的结构，使得程序可以通过可组合性（compositional）来显著降低其复杂性，提升安全性；
• 如何将上述工作在现有项目中低成本、渐进式应用；
• 尝试声明式的思考问题：想要做什么，而不是该怎么做。

我们编程时多少会遇到需要处理“时间”的情况，在各语言平台下通常也会内置时间相关的API。“时间”作为一个问题领域：第一，非常常见；第二，往往比我们想象的要复杂！因此程序员常会因为轻视它而踩坑。实际上，就连语言和库设计者也不能例外。JavaScript语言在1995年诞生时因为只有十天时间，并且因为管理层要求“像Java”，所以内建的Date直接照搬了Java 1.0中java.util.Date的设计。然而该API却非常糟糕，以至于在1997年Java 1.1中就被deprecated了。不幸的是，因为种种原因，此API却一直在JavaScript中沿袭了20多年至今。这些年以来，在JavaScript社区中出现了许多非常优秀的类库和框架，2011年诞生的Moment.js作为一个仅仅专门用于时间处理的库，也忝列其中。然而Moment.js至今仍然有一些重大缺陷。另一方面，Java 1.1之后的java.util.Calendar也仍然一直被诟病，从而出现了如Joda-Time这样的库，并成为了事实标准。可是Joda-Time也不是没有问题。最终直到2014年发布的Java 8，才包含了重新设计的java.time包。以Java和JavaScript为代表的主流工业语言及其社区的历史经验证明，设计一个好的时间API远比我们想象的要困难得多。本次分享将以JavaScript语言标准新的Temporal提案为核心，结合前述历史，探讨“时间”这一领域的各种编程问题和API设计问题。