CPU的cache往往是分多级的金字塔模型，L1最靠近CPU，访问延迟最小，但cache的容量也最小。首先，根据wikichip[1]，获得CPU 各级cache延迟的基准值（以skylake为例）：Cache LatencyCPU Frequency:2654MHz (0.3768 nanosec/clock)Cache/LatencySizeCycleNanosecondL132 KB/core41.5072L21024 KB/core145.2752L31.375 MB/core（33 MB/socket）50-7018.84-26.37Wikichip提供了不同CPU型号的cache延迟，单位一般为cycle，通过简单的运算，转换为ns。​设计实验1. Naive thinking申请一个buffer，buffer size为cache对应的大小，第一次遍历进行预热，将数据全部加载到cache中。第二次遍历统计耗时，计算每次read的延迟平均值。​代码实现mem-lat.c如下：#define ONE p = (char **)*p; #define FIVE ONE ONE ONE ONE ONE #define TEN FIVE FIVE #define FIFTY TEN TEN TEN TEN TEN #define HUNDRED FIFTY FIFTY int main() { //... char* mem = mmap(NULL, memsize, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); // trick3: init pointer chasing, per stride=8 byte size = memsize / stride; indices = malloc(size * sizeof(int)); for (i = 0; i < size; i++) indices[i] = i; // trick 2: fill mem with pointer references for (i = 0; i < size - 1; i++) *(char **)&mem[indices[i]*stride]= (char*)&mem[indices[i+1]*stride]; *(char **)&mem[indices[size-1]*stride]= (char*)&mem[indices[0]*stride]; char **p = (char **) mem; tmp = count / 100; gettimeofday (&tv1, &tz); for (i = 0; i < tmp; ++i) { HUNDRED; //trick 1 } gettimeofday (&tv2, &tz); //... }这里用到了3个小技巧：HUNDRED宏：通过宏展开，尽可能避免其他指令对访存的干扰。二级指针：通过二级指针将buffer串起来，避免访存时计算偏移。char和char*为8字节，因此，stride为8。测试结果如下：//L1 Buffer size: 1 KB, stride 8, time 0.003921 s, latency 3.74 ns Buffer size: 2 KB, stride 8, time 0.003928 s, latency 3.75 ns Buffer size: 4 KB, stride 8, time 0.003935 s, latency 3.75 ns Buffer size: 8 KB, stride 8, time 0.003926 s, latency 3.74 ns Buffer size: 16 KB, stride 8, time 0.003942 s, latency 3.76 ns Buffer size: 32 KB, stride 8, time 0.003963 s, latency 3.78 ns //L2 Buffer size: 64 KB, stride 8, time 0.004043 s, latency 3.86 ns Buffer size: 128 KB, stride 8, time 0.004054 s, latency 3.87 ns Buffer size: 256 KB, stride 8, time 0.004051 s, latency 3.86 ns Buffer size: 512 KB, stride 8, time 0.004049 s, latency 3.86 ns Buffer size: 1024 KB, stride 8, time 0.004110 s, latency 3.92 ns //L3 Buffer size: 2048 KB, stride 8, time 0.004126 s, latency 3.94 ns Buffer size: 4096 KB, stride 8, time 0.004161 s, latency 3.97 ns Buffer size: 8192 KB, stride 8, time 0.004313 s, latency 4.11 ns Buffer size: 16384 KB, stride 8, time 0.004272 s, latency 4.07 ns相比基准值，L1延迟偏大，L2和L3延迟偏小，不符合预期。​2. Thinking with hardware: cache line现代处理器，内存以cache line为粒度，组织在cache中。访存的读写粒度都是一个cache line，最常见的缓存线大小是64字节。如果我们简单的以8字节为粒度，顺序读取128KB的buffer，假设数据命中的是L2，那么数据就会被缓存到L1，一个cache line其他的访存操作都只会命中L1，从而导致我们测量的L2延迟明显偏小。​本文测试的CPU，cacheline大小64字节，只需将stride设为64。测试结果如下：//L1 Buffer size: 1 KB, stride 64, time 0.003933 s, latency 3.75 ns Buffer size: 2 KB, stride 64, time 0.003930 s, latency 3.75 ns Buffer size: 4 KB, stride 64, time 0.003925 s, latency 3.74 ns Buffer size: 8 KB, stride 64, time 0.003931 s, latency 3.75 ns Buffer size: 16 KB, stride 64, time 0.003935 s, latency 3.75 ns Buffer size: 32 KB, stride 64, time 0.004115 s, latency 3.92 ns //L2 Buffer size: 64 KB, stride 64, time 0.007423 s, latency 7.08 ns Buffer size: 128 KB, stride 64, time 0.007414 s, latency 7.07 ns Buffer size: 256 KB, stride 64, time 0.007437 s, latency 7.09 ns Buffer size: 512 KB, stride 64, time 0.007429 s, latency 7.09 ns Buffer size: 1024 KB, stride 64, time 0.007650 s, latency 7.30 ns Buffer size: 2048 KB, stride 64, time 0.007670 s, latency 7.32 ns //L3 Buffer size: 4096 KB, stride 64, time 0.007695 s, latency 7.34 ns Buffer size: 8192 KB, stride 64, time 0.007786 s, latency 7.43 ns Buffer size: 16384 KB, stride 64, time 0.008172 s, latency 7.79 ns虽然相比方案1，L2和L3的延迟有所增大，但还是不符合预期。​3. Thinking with hardware: prefetch现代处理器，通常支持预取（prefetch）。数据预取通过将代码中后续可能使用到的数据提前加载到cache中，减少CPU等待数据从内存中加载的时间，提升cache命中率，进而提升软件的运行效率。Intel处理器支持4种硬件预取[2]，可以通过MSR控制关闭和打开：PrefetcherBit# in MSR 0x1A4DescriptionL2 hardware prefetcher0Fetches additional lines of code or data into the L2 cacheL2 adjacent cache line prefetcher1Fetches the cache line that comprises a cache line pair (128 bytes)DCU prefetcher2Fetches the next cache line into L1-D cacheDCU IP prefetcher3Uses sequential load history (based on Instruction Pointer of previous loads) to determine whether to prefetch additional lines这里我们简单的将stride设为128和256，避免硬件预取。测试的L3访存延迟明显增大：// stride 128 Buffer size: 1 KB, stride 256, time 0.003927 s, latency 3.75 ns Buffer size: 2 KB, stride 256, time 0.003924 s, latency 3.74 ns Buffer size: 4 KB, stride 256, time 0.003928 s, latency 3.75 ns Buffer size: 8 KB, stride 256, time 0.003923 s, latency 3.74 ns Buffer size: 16 KB, stride 256, time 0.003930 s, latency 3.75 ns Buffer size: 32 KB, stride 256, time 0.003929 s, latency 3.75 ns Buffer size: 64 KB, stride 256, time 0.007534 s, latency 7.19 ns Buffer size: 128 KB, stride 256, time 0.007462 s, latency 7.12 ns Buffer size: 256 KB, stride 256, time 0.007479 s, latency 7.13 ns Buffer size: 512 KB, stride 256, time 0.007698 s, latency 7.34 ns Buffer size: 512 KB, stride 128, time 0.007597 s, latency 7.25 ns Buffer size: 1024 KB, stride 128, time 0.009169 s, latency 8.74 ns Buffer size: 2048 KB, stride 128, time 0.010008 s, latency 9.55 ns Buffer size: 4096 KB, stride 128, time 0.010008 s, latency 9.55 ns Buffer size: 8192 KB, stride 128, time 0.010366 s, latency 9.89 ns Buffer size: 16384 KB, stride 128, time 0.012031 s, latency 11.47 ns // stride 256 Buffer size: 512 KB, stride 256, time 0.007698 s, latency 7.34 ns Buffer size: 1024 KB, stride 256, time 0.012654 s, latency 12.07 ns Buffer size: 2048 KB, stride 256, time 0.025210 s, latency 24.04 ns Buffer size: 4096 KB, stride 256, time 0.025466 s, latency 24.29 ns Buffer size: 8192 KB, stride 256, time 0.025840 s, latency 24.64 ns Buffer size: 16384 KB, stride 256, time 0.027442 s, latency 26.17 nsL3的访存延迟基本上是符合预期的，但是L1和L2明显偏大。​如果测试随机访存延迟，更加通用的做法是，在将buffer指针串起来时，随机化一下。 // shuffle indices for (i = 0; i < size; i++) { j = i + rand() % (size - i); if (i != j) { tmp = indices[i]; indices[i] = indices[j]; indices[j] = tmp; } }可以看到，测试结果与stride为256基本上是一样的。Buffer size: 1 KB, stride 64, time 0.003942 s, latency 3.76 ns Buffer size: 2 KB, stride 64, time 0.003925 s, latency 3.74 ns Buffer size: 4 KB, stride 64, time 0.003928 s, latency 3.75 ns Buffer size: 8 KB, stride 64, time 0.003931 s, latency 3.75 ns Buffer size: 16 KB, stride 64, time 0.003932 s, latency 3.75 ns Buffer size: 32 KB, stride 64, time 0.004276 s, latency 4.08 ns Buffer size: 64 KB, stride 64, time 0.007465 s, latency 7.12 ns Buffer size: 128 KB, stride 64, time 0.007470 s, latency 7.12 ns Buffer size: 256 KB, stride 64, time 0.007521 s, latency 7.17 ns Buffer size: 512 KB, stride 64, time 0.009340 s, latency 8.91 ns Buffer size: 1024 KB, stride 64, time 0.015230 s, latency 14.53 ns Buffer size: 2048 KB, stride 64, time 0.027567 s, latency 26.29 ns Buffer size: 4096 KB, stride 64, time 0.027853 s, latency 26.56 ns Buffer size: 8192 KB, stride 64, time 0.029945 s, latency 28.56 ns Buffer size: 16384 KB, stride 64, time 0.034878 s, latency 33.26 ns4. Thinking with compiler: register keyword解决掉L3偏小的问题后，我们继续看L1和L2偏大的原因。为了找出偏大的原因，我们先反汇编可执行程序，看看执行的汇编指令是否是我们想要的： objdump -D -S mem-lat > mem-lat.s-D: Display assembler contents of all sections.-S：Intermix source code with disassembly. (gcc编译时需使用-g，生成调式信息)生成的汇编文件mem-lat.s： char **p = (char **)mem; 400b3a: 48 8b 45 c8 mov -0x38(%rbp),%rax 400b3e: 48 89 45 d0 mov %rax,-0x30(%rbp) // push stack //... HUNDRED; 400b85: 48 8b 45 d0 mov -0x30(%rbp),%rax 400b89: 48 8b 00 mov (%rax),%rax 400b8c: 48 89 45 d0 mov %rax,-0x30(%rbp) 400b90: 48 8b 45 d0 mov -0x30(%rbp),%rax 400b94: 48 8b 00 mov (%rax),%rax首先，变量mem赋值给变量p，变量p压入栈-0x30(%rbp)。 char **p = (char **)mem; 400b3a: 48 8b 45 c8 mov -0x38(%rbp),%rax 400b3e: 48 89 45 d0 mov %rax,-0x30(%rbp)访存的逻辑： HUNDRED; // p = (char **)*p 400b85: 48 8b 45 d0 mov -0x30(%rbp),%rax 400b89: 48 8b 00 mov (%rax),%rax 400b8c: 48 89 45 d0 mov %rax,-0x30(%rbp)先从栈中读取指针变量p的值到rax寄存器（变量p的类型为char **，是一个二级指针，也就是说，指针p指向一个char *的变量，即p的值也是一个地址）。下图中变量p的值为0x2000。将rax寄存器指向变量的值读入rax寄存器，对应单目运算*p。下图中地址0x2000的值为0x3000，rax更新为0x3000。将rax寄存器赋值给变量p。下图中变量p的值更新为0x3000。根据反汇编的结果可以看到，期望的1条move指令被编译成了3条，cache的延迟也就增加了3倍。​C语言的register关键字，可以让编译器将变量保存到寄存器中，从而避免每次从栈中读取的开销。It's a hint to the compiler that the variable will be heavily used and that you recommend it be kept in a processor register if possible.我们在声明p时，加上register关键字。register char **p = (char **)mem;​测试结果如下：// L1 Buffer size: 1 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 2 KB, stride 64, time 0.000029 s, latency 0.03 ns Buffer size: 4 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 8 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 16 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 32 KB, stride 64, time 0.000030 s, latency 0.03 ns // L2 Buffer size: 64 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 128 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 256 KB, stride 64, time 0.000029 s, latency 0.03 ns Buffer size: 512 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 1024 KB, stride 64, time 0.000030 s, latency 0.03 ns // L3 Buffer size: 2048 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 4096 KB, stride 64, time 0.000029 s, latency 0.03 ns Buffer size: 8192 KB, stride 64, time 0.000030 s, latency 0.03 ns Buffer size: 16384 KB, stride 64, time 0.000030 s, latency 0.03 ns访存延迟全部变为不足1 ns，明显不符合预期。​5. thinking with compiler: Touch it！重新反汇编，看看哪里出了问题，编译代码如下： for (i = 0; i < tmp; ++i) { 40155e: 48 c7 45 f8 00 00 00 movq $0x0,-0x8(%rbp) 401565: 00 401566: eb 05 jmp 40156d <main+0x37e> 401568: 48 83 45 f8 01 addq $0x1,-0x8(%rbp) 40156d: 48 8b 45 f8 mov -0x8(%rbp),%rax 401571: 48 3b 45 b0 cmp -0x50(%rbp),%rax 401575: 72 f1 jb 401568 <main+0x379> HUNDRED; } gettimeofday (&tv2, &tz); 401577: 48 8d 95 78 ff ff ff lea -0x88(%rbp),%rdx 40157e: 48 8d 45 80 lea -0x80(%rbp),%rax 401582: 48 89 d6 mov %rdx,%rsi 401585: 48 89 c7 mov %rax,%rdi 401588: e8 e3 fa ff ff callq 401070 <gettimeofday@plt>HUNDRED宏没有产生任何汇编代码。涉及到变量p的语句，并没有实际作用，只是数据读取，大概率被编译器优化掉了。 register char **p = (char **) mem; tmp = count / 100; gettimeofday (&tv1, &tz); for (i = 0; i < tmp; ++i) { HUNDRED; } gettimeofday (&tv2, &tz); /* touch pointer p to prevent compiler optimization */ char **touch = p;反汇编验证一下： HUNDRED; 401570: 48 8b 1b mov (%rbx),%rbx 401573: 48 8b 1b mov (%rbx),%rbx 401576: 48 8b 1b mov (%rbx),%rbx 401579: 48 8b 1b mov (%rbx),%rbx 40157c: 48 8b 1b mov (%rbx),%rbxHUNDRED宏产生的汇编代码只有操作寄存器rbx的mov指令，高级。延迟的测试结果如下：// L1 Buffer size: 1 KB, stride 64, time 0.001687 s, latency 1.61 ns Buffer size: 2 KB, stride 64, time 0.001684 s, latency 1.61 ns Buffer size: 4 KB, stride 64, time 0.001682 s, latency 1.60 ns Buffer size: 8 KB, stride 64, time 0.001693 s, latency 1.61 ns Buffer size: 16 KB, stride 64, time 0.001683 s, latency 1.61 ns Buffer size: 32 KB, stride 64, time 0.001783 s, latency 1.70 ns // L2 Buffer size: 64 KB, stride 64, time 0.005896 s, latency 5.62 ns Buffer size: 128 KB, stride 64, time 0.005915 s, latency 5.64 ns Buffer size: 256 KB, stride 64, time 0.005955 s, latency 5.68 ns Buffer size: 512 KB, stride 64, time 0.007856 s, latency 7.49 ns Buffer size: 1024 KB, stride 64, time 0.014929 s, latency 14.24 ns // L3 Buffer size: 2048 KB, stride 64, time 0.026970 s, latency 25.72 ns Buffer size: 4096 KB, stride 64, time 0.026968 s, latency 25.72 ns Buffer size: 8192 KB, stride 64, time 0.028823 s, latency 27.49 ns Buffer size: 16384 KB, stride 64, time 0.033325 s, latency 31.78 nsL1延迟1.61 ns，L2延迟5.62 ns，终于，符合预期！写在最后本文的思路和代码参考自lmbench[3]，和团队内大佬雏燕的工具mem-lat[4]。最后给自己挖个坑，在随机化buffer指针时，没有考虑硬件TLB miss的影响，如果有读者有兴趣，待日后有空补充。参考文献：[1]https://en.wikichip.org/wiki/intel/microarchitectures/skylake_(server))[2]https://software.intel.com/content/www/us/en/develop/articles/disclosure-of-hw-prefetcher-control-on-some-intel-processors.html[3]McVoy L W, Staelin C. lmbench: Portable Tools for Performance Analysis[C]//USENIX annual technical conference. 1996: 279-294.[4]http://gitlab.alibaba-inc.com/qos/tools/blob/master/memory/mem-lat.c

前言本篇文章是 TypeScript的另一面：类型编程 系列的第 1 篇，这一系列将发布在同名专栏中（见 知乎专栏 或 掘金专栏）。同时，这一系列的文章将主要继承于笔者在去年的同名文章（原版，炒冷饭版）内容中各部分，并进行进一步扩展深入，除本篇的 never 类型以外，还将包括如条件类型与协变 & 逆变、infer与递归 & 尾递归、TypeScript中的控制流分析、TypeScript 工具链的探索等部分，欢迎关注。至于会有这个系列的原因，首先是因为这篇文章原版其实阅读还蛮广的，不论在内网外网，可能都是我目前阅读最高、受众最广的一篇。而在这篇文章中，我尝试把绝大部分的内容都塞进去，导致并不是所有人都能读下来，或者读下来都能还保持神志清醒。同时，原文中的部分内容在今天的笔者看来也显得有些太浅太泛了（水平有限，还望见谅）。所以就有了这个系列，区别于一股脑填鸭，这个系列的每一篇文章只会关注一个独立的问题，因此保证了内容纯粹（就跟笔者的人格一样纯粹） + 篇幅精简。最重要的是，本系列文章默认你已经拥有 TypeScript 的基础，阅读过之前的专栏文章更好。另外，本文以及本系列内容部分来自于笔者将在 12月 QCon+「TypeScript 在中大型项目中的落地实践」 专题中进行的分享，同样欢迎关注。本篇主要从以下部分出发，介绍 TypeScript 的 never 类型，由于笔者才疏学浅，未曾了解过其他计算机语言中的类型系统知识，如果出现错漏，还望不吝指出。TypeScript 中的三个特殊类型：any、unknown、never如果只用 never，我们可以做到什么？never 在工具类型中的作用在开始前，感谢 雪碧老师、阿伟、寻找海蓝、三七二十 等前辈的 TypeScript 相关分享，本文内容也大量受到他们的影响，再次向以上前辈的分享精神致敬。P.S. 你可以在 GitHub 获取所有示例代码。never、any、unknown在 TypeScript 中，有这么几个类型可能一直困扰着初学者们，any、unknown 以及 never，这都是啥玩意啊？？啥时候用 any，啥时候用 unknown，never 好像没见过人用？先想想我们一般啥时候用 any，比如某个变量实际上就是某个类型，但是由于中途各种操作你没做的严丝合缝，到某一步类型报错了，这个时候可以先 as 成 any，再 as 成你想要的类型，然后你就又有类型提示了（当然，我觉得直接 as any 的情况比较多）。// 要是你在公司这么写代码被打了，别把我供出来 const foo = {} as any as Function;as 意味着什么？你指着编译器的脸告诉它，这个变量的类型就是这个，不服憋着。为什么要 as 两次？不能直接 as Function？好问题！因为 TS编译器会用报错狠狠的抽你 as 实际上只能转换存在父子类型的关系，对于风马牛不相及的关系它是不理你的，所以你需要先 as 成 any，像中介一样强行把原类型和新类型关联起来。如果要稍微规范一点，应该先 as 成原类型和新类型的父类型，再 as 成新类型，如雪碧老师的例子：// Deer、Horse的公共父类型 interface Animal {} interface Deer extends Animal { deerId: number } interface Horse extends Animal { horseId: number } let deer: Deer = { deerId: 0 } // 并不能一步到位 let horse = deer as Horse // 先提升成共同的父类型，再定位到子类型 let horse = deer as Animal as Horse后来，我们有了 unknown，编译器对于关联不相关的两个类型的提示也变成了 “求求你先 as 成 unknown 吧”，那么 unknown 和 any 有啥区别？首先，在 TypeScript 的类型系统中，any 与 unknown 都属于 Top Type（在大部分类型语言中都有这么个玩意，如 PHP 中的 mixed，Kotlin中的 Any? 等），也就是说在类型层级中它们位于顶点，但 any 类型的变量可以被赋值以任意类型的值，而 unknown 则只能接受 unknown 与 any。二者的出发点其实是一致的，那就是快速表示一个未知/动态的值，但 any 显然更加无拘无束：let foo: any; foo.bar().baz();这样都不会报错！和 JavaScript 还有啥区别（狗头），使用 any 意味着你在这里其实完全放弃了类型检查，更可怕的是 any 的传染性，一个变量被声明为 any，那么接下来所有基于其操作派生来的值就都被打上了隐式 any（如果没有类型断言或者基于控制流分析的类型收窄）。但 unknown 不一样，它就像是类型安全版本的any：因为类型检查仍然存在。let bar: unknown; // 这里是会报错的 // @ts-expect-error bar.baz().foo();对于被声明为 unknown 的变量，你没法直接读写它，而是必须先指定类型，显式指定、类型守卫、编译器的自动分析都行，比如类型守卫：function isString(input: unknown): input is string { return typeof input === "string"; }既然有 Top Type，那么就应该要有 Bottom Type，在 TypeScript 中 never 就是那个 Bottom Type。Bottom Type 意味着一个不表示任何类型的类型，在 Kotlin 中它是 Nothing，在 Rust 中则用 ! 修饰一个没有返回值的类型。你可能觉得，string 已经挺具体了，'linbudu' 这种字面量类型就更具体了，但 never 还要更具体。它是所有类型的子类型，是类型系统的最底层，也就意味着没有任何类型可以赋给它，除了 never 本身。在 TypeScript 中，一个必定抛出错误的函数，它的返回值就是 never。说到这里你可能会想还有一个特殊的小伙伴 void（我们经常会写 Promise<void> 来表示一个直接 resolve 掉的 Promise），而 void 和 never 的区别就在于，返回 void 的函数其内部还是会调用 return 语句，只不过它啥也没返回，void 代表啥类型也没有（甚至 void 其实并不应该被看做一个类型），而返回 never 的函数其内部压根就没有调用 return 语句，never 代表返回压根就不存在，哪来的类型捏。了解了 never 的基础概念，接下来要准备用用它了:)最基本的 never 使用never 单独使用的场景是非常少的，但也不是没有，我们前面说过，它是任何类型的子类型，没有比它更 narrow 的类型，所以就不可能被复制给 never 类型。我们可以使用这一点来确保在 if...else 或者 swicth case 语句中，所有可能的(类型)分支都被穷举到。在 TSConfig 中，有个类似的 noImplicitReturns 选项，它确保了函数的所有路径分支都必须返回值，但很明显粒度（也可以说力度）并不够。一个简单的例子，某个变量使用联合类型定义：const strOrNum: string | number = "foo"; if (typeof strOrNum === "string") { console.log("str!"); } else if (typeof strOrNum === "number") { console.log("num!"); } 看起来好像没啥问题，假设某天这个变量的联合类型又多了一个成员：const strOrNumOrBool: string | number | boolean = false;而一个很经常出现的场景是，你需要这个变量所有可能的联合类型都被处理到，并对每一个联合类型的成员进行特殊处理。在上面的代码中，如果你忘记了处理 boolean 类型的情况，TypeScript 也不会报错（当然不会了，如果它能智能到这种程度，干脆改名叫 AIScript 好了）。那么，要怎么在漏处理类型分支的时候抛出错误？首先，由于 TypeScript 的类型收窄能力，我们能在每一个 else 的 语法块中将变量的类型收窄到对应的值。如果我们在上面的语句中加一个 兜底的 else 语句：const strOrNumOrBool: string | number | boolean = "foo"; if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else { // ... }在最后的 else 语句块中，如果我们还使用这个变量，那么它就会被智能推导为 boolean 类型。这肯定不是我们想看到的，它都走到兜底语句块了还有未收窄过的类型。所以我们简单粗暴的把它赋值为 never（回到最开始的例子）：const strOrNumOrBool: string | number | boolean = false; if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else { const _exhaustiveCheck: never = strOrNumOrBool; }好的，报错来了：不能将类型“boolean”分配给类型“never”。ts(2322)我们再加上一个处理 boolean 类型的分支：if (typeof strOrNumOrBool === "string") { console.log("str!"); } else if (typeof strOrNumOrBool === "number") { console.log("num!"); } else if (typeof strOrNumOrBool === "boolean") { console.log("bool!"); } else { const _exhaustiveCheck: never = strOrNumOrBool; }现在就没问题了，因为在穷举完所有类型分支后，strOrNumOrBool的类型当然就也是 never 啦。这样做只是从 TypeScript 类型层面避免了遗漏，为了安全起见，我们可以在 else 兜底语句中抛出一个错误：// ... else { const _exhaustiveCheck: never = strOrNumOrBool; throw new Error(`Unknown input type: ${_exhaustiveCheck}`); }一个类似的场景，枚举 + switch case 语句，可能是最常见的组合之一：enum PossibleType { Foo = "Foo", Bar = "Bar", Baz = "Baz", } function checker(input: PossibleType) { switch (input) { case PossibleType.Foo: console.log("foo!"); break; case PossibleType.Bar: console.log("bar!"); break; case PossibleType.Baz: console.log("baz!"); break; default: const _exhaustiveCheck: never = input; break; } }现在这个是没有问题的，可是一旦你在枚举值中新增了一个成员（见示例），就会出现不能赋值给 never 的报错提示。在工具类型中大显身手好的，又到了喜闻乐见的工具类型环节，多少同学曾为了一个洋洋洒洒几十行的工具类型挠破头。其实吧，对于类型体操这一类，我感觉会中级的基本上就够了，你在写业务的时候来一个巨复杂巨绕十几个泛型参数的工具类型，你看同事会不会捶你。回到 never，never在工具类型中的作用其实可以概括为三个方面：作为泛型参数的默认值，以支持工具类型内部，基于入参个数变化的类型处理逻辑。与 infer + 条件类型结合，提取符合特定 Type Structure 的特定位置的值，如果待提取的类型参数不符合此结构，则返回 never。通过将接口中的部分属性指定为 never，去除其中的某些属性，以此来实现裁剪/组装/扩展接口。首先是作为泛型参数的默认值，上一个稍微绕点的例子：type Equal<X, Y, A = X, B = never> = (<T>() => T extends X ? 1 : 2) extends < T >() => T extends Y ? 1 : 2 ? A : B;严格来说，这个例子和第一点并没有特别大的关系，但这会是后面比较重要的工具类型的基础，同时也普遍被反馈比较难理解，所以这里扔上来提前讲解一下。这个结构是不是还挺诡异的，1 和 2 是什么东西，为什么 extends 里面还有泛型，这个 A 和 B 又是干啥的？定睛一看（对不起，最近郭德纲和于谦两位老师的相声听多了，定睛一看老是想到...），其实就是两个东西作比较：(<T>() => T extends X ? 1 : 2) 和 (<T>() => T extends X ? 1 : 2)，再定睛一看，这不就是一样的两坨吗。等等，T 又哪来的？再一个个来，首先这个结构就是，如果 (<T>() => T extends X ? 1 : 2) 能够 extends (<T>() => T extends Y ? 1 : 2)，那就返回 A，否则返回 B。关于 extends，这涉及到协变与逆变相关的部分，在这里你可以简单理解为，左边的类型更加狭窄具体，右边的类型更加宽松广泛时（即，右边类型中有的在左边肯定有！），extends 成立：// "TRUE" type Test = { foo: string; bar: boolean; } extends { foo: string } ? "TRUE" : "FALSE";这个泛型 T，你会发现它实际上也没有具体的值，而是作为整个 (<T>() => T extends X ? 1 : 2) 结构的一部分参与到比较当中（毕竟才刚定义嘛，通过<T>）。在这个例子中我们其实只是用这个套了一层作为条件，来比较 X 与 Y 是否相等。诶，怎么又变相等了，说好的 extends 是一个狭窄一个宽松呢？仔细看老伙计，这里不是简单的 X extends Y，不然我为啥要外面套一层这东西？通过将 X 与 Y 放置在临时函数的返回值中间接判定，确保了只有在 X 与 Y 完全一致时才能通过 extends。这里的完全一致指修饰符啥的也一致，比如两个接口的话，接口A的属性 foo 是只读 readonly 的，那接口 B 的属性 foo 就也得是只读的，一个简单例子：// fail type TestEqual1 = Equal<[], readonly [], "pass", "fail">; // pass type TestEqual2 = Equal<[], [], "pass", "fail">;再看这里的 A 和 B，其实就是决定了 extends 通过与否对应的返回值，这里的 A = X 和 B = never 其实和它实际的场景有关，完全可以不写或者自由发挥。下一点，与 infer + 条件类型结合，说到这我可就不困了啊，毕竟这是最简单的场景了，甚至可以直接看例子就行。当然，前提是你了解 infer。type FuncReturnType<T extends (...args: any) => any> = T extends ( ...args: any ) => infer R ? R : never;基本上所有进行单次提取行为的工具类型都是这个结构，比如 TS 4.5 新增的 Awaited（或者叫 PromiseValue），提取一个 Promise 的内部类型；同样是内置的 Parameters（提取函数参数类型）、ConstructorParameters （提取构造函数参数类型），都是这么个套路，没啥意思。然后是不带 infer 玩，never 和条件类型搞小团体的版本，这种单次判断也很简单，比如 Exclude、Extract 两兄弟：type Exclude<T, U> = T extends U ? never : T; type Extract<T, U> = T extends U ? T : never;看起来好像很朴素，那是因为这里的 T 和 U 通常是联合类型为多，如：interface Tmp1 { foo: string; bar: string; baz: string; } interface Tmp2 { foo: string; baz: string; } // "bar" type ExcludedKeys = Exclude<keyof Tmp1, keyof Tmp2>; // "foo" | "baz"; type ExtractedKeys = Extract<keyof Tmp1, keyof Tmp2>;当然，你也可以把 keyof 封装进去，即type ExcludedKeys<T, U> = keyof T extends keyof U ? never : keyof T; type ExtractedKeys<T, U> = keyof T extends keyof U ? keyof T : never;为什么不呢？我希望看到这里，你已经摸到了一丝 never 实际作用的曙光，即它在工具类型里到底起什么作用，如果没有也没关系，不然我这摊子就摆不下去了。接下来我们来看一些更常见、更强大的 never 应用吧。先来看这样一个接口：interface ITmp { foo: number; bar: string; baz: never; }你猜使用这个接口的对象能不能有 baz 属性？事出无常必有妖，所以这里肯定是不行。这么一个接口有作用？好像是没有，显式的声明 never 意味着你都知道有哪些属性是需要剔除（而且需要手动声明）的了。那如果我们通过各种体操动作，最后得到这个接口呢？这也是 never 的第三种作用，也是我个人认为最强大最 Amazing 的一种：通过将接口中的部分属性指定为 never，去除其中的某些属性，以此来实现裁剪/组装/扩展接口。我们可以通过使用 映射类型 + 条件类型 很容易的得到这种结构的接口，如type ProcessedTypeWithNonFuncPropAsNever<T extends object> = { [K in keyof T]-?: T[K] extends Function ? K : never; }; interface IInterfaceWithFuncProps { foo: string; bar: string; func1: () => void; func2: () => void; }好吧这个名字有点小长，将就一下好了，一直 foo bar baz 怪敷衍的。这里的 -? 意为去除 ?: 标志。这个得到的结果是：type Result = ProcessedTypeWithNonFuncPropAsNever<IInterfaceWithFuncProps> type Result = { foo: never; bar: never; fun1: "func1"; func2: "func2"; }这个好像没啥用啊？函数还可以更近一步，获取所有函数类型的键组成的联合类型，比如 "foo1" | "foo2"，只需要加上一点小小的东西：type FuncTypeKeys<T extends object> = { [K in keyof T]-?: T[K] extends Function ? K : never; }[keyof T]; // "func1" | "func2" type Result = FuncTypeKeys<IInterfaceWithFuncProps>把 T[K] extends Function ? K : never; 改成 T[K] extends Function ? T[K] : never; 就可以直接拿到值啦。这个可能简单了点，看个稍微复杂点的：type MutableKeys<T extends object> = { [P in keyof T]-?: Equal< { [Q in P]: T[P] }, { -readonly [Q in P]: T[P] }, P, never >; }[keyof T]; type Equal<X, Y, A = X, B = never> = (<T>() => T extends X ? 1 : 2) extends < T >() => T extends Y ? 1 : 2 ? A : B;如果前面没有讲过 Equal 这个类型的作用的话，那这个 MutableKeys 还是要皱眉看它个三五分钟才能看懂的，但讲过就好办多了。我们前面讲过 Equal 中的 extends 需要两边的类型完全一致，包括修饰符如 readonly 以及 ?，所以我相信你大概还是没看懂，拆开来看：首先用映射类型把这个接口的键提取出来：[P in keyof T]然后再对这个键提取一次：{ [Q in P]: T[P] } 与 { -readonly [Q in P]: T[P] }使用 Equal 比较上面的两个提取，并在比较通过时返回第一步中首次提取的键。对于第二步，我们实现一个中介类型：interface IInterfaceWithReadonlyProps { readonly foo: string; bar: string; readonly func1: () => void; func2: () => void; } type Tmp<T extends object> = { [P in keyof T]-?: { [Q in P]: T[P] }; }; type A1 = Tmp<IInterfaceWithReadonlyProps>;这个 A1 的类型大概是这样：type A1 = { readonly foo: { readonly foo: string; }; bar: { bar: string; }; readonly func1: { readonly func1: () => void; }; func2: { func2: () => void; }; }其实就是 K:V 变成了 K:(K:V) 的形式，为啥要这么做嘞？我们在比较时为 Equal 中的 Y 传入了去掉最外层 readonly 的版本，就变成了 readonly foo: { readonly foo: string } vs foo: { readonly foo: string } ！很明显这两个比较是通不过的，那么就说明 foo 肯定是只读的，MutableKeys 里不准有它！比起来 readonly，可能 ?: optional 更多一些，那实现个 OptionalKeys 吧：export type OptionalKeys<T> = { [K in keyof T]-?: {} extends Pick<T, K> ? K : never; }[keyof T];我们前面说过，extends 的左边不能比右边更宽松，所以，{} extends { a:number } 肯定不成立，但是 {} extends { a?: number } 可以，所以使用 Pick 择出来可选类型就好了。好了，美好时光总是短暂的，我也没估计读到这里大概要多久，十分钟应该要吧，让我们最后再看一个实用的工具类型，然后请关闭手机/电脑屏幕，做五分钟眼保健操。我们经常遇到这种场景：某个对象同时只能且必须满足多个接口之一，比如如果你是普通用户，那么肯定就不是 VIP。某个对象中同时只能有多组属性之一，比如你要么有普通用户才有的属性（距离下一次赠送 VIP 体验券还有多久），要么有 VIP 用户才有的属性（VIP等级）某个对象中的数个属性必须同时存在或不存在，比如你要么同时有 VIP 用户才有的 VIP等级 和 VIP到期时间，要么啥也冇。这些场景其实全部可以抽象为一种，互斥类型，而用 never 来实现可能是最优雅简单的办法。比如第二种情况，其实就是 { sendVIPExpTime: number; vipLevel: never; } | { sendVIPExpTime: never; vipLevel: number; } ，实现也很简单：type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never }; type XOR<T, U> = (Without<T, U> & U) | (Without<U, T> & T);我觉得这个应该不用解释了吧，看看效果：interface Foo { foo: string; } interface Bar { bar: string; } // foo + bar:never | bar + foo:never type FooOrBar = XOR<Foo, Bar>; const fooOrBar1: FooOrBar = { foo: "foo" }; const fooOrBar2: FooOrBar = { bar: "bar" }; // Error // @ts-expect-error const fooOrBar3: FooOrBar = { baz: "baz" }; // Error // @ts-expect-error const fooOrBar4: FooOrBar = { foo: "foo", bar: "bar" };以及至少满足一种备选类型的情况：// 必须有sharedProp，container、module至少有其中一个 // 如果去掉 Partial，则是必须至少有一个 type ComposedOption = { sharedProp: string } & Partial< XOR< { container: { containerId: number; }; }, { module: { modId: number }; } > >; const option: ComposedOption = { sharedProp: "foo", container: { containerId: 599, }, };写到这里，全文也该结束了。其实这篇文章还是超出了我对精简的预期，毕竟很多知识点都是牵一发而动全身（尤其是工具类型部分），如果直接扔出来的话就只能我和读者四眼懵逼了。本篇文章作为此系列的第一篇，应该是存在着很多不足的，比如我听着相声写下这篇文章，让它显得不是很严肃...，但也希望你能从中学到一些，再提醒一下，你可以在 GitHub 找到此系列的所有代码，我们明年下次再见。

背景在日常编码中，经常会遇到需要栈回溯的场景，比如异常上报，动态 Hook（判断来自哪个函数）等等。那么在 Android 中怎么进行栈回溯呢，最近研究了一下这个问题。理论上像栈回溯这种通用场景，应该有系统函数可以实现，那么系统函数又有什么问题呢，为什么有这篇踩坑文，接下来一一讲解。栈回溯的理论基础写一个简单的函数调用如下。void func4(int a, int b, int c, int d, int e) { __android_log_print(ANDROID_LOG_INFO, "backtrace", "func"); } void func3(int a, int b, int c, int d, int e, int f, int g, int h) { func4(1,2,3,4,5); } void func2(int a, int b, int c) { func3(1,2,3,4,5,6,7,8); } void func1(int a) { func2(1, 2, 3); } extern "C" JNIEXPORT jstring JNICALL Java_com_example_backtrackdemo_MainActivity_stringFromJNI( JNIEnv* env, jobject /* this */) { func1(1); std::string hello = "Hello from C++"; return env->NewStringUTF(hello.c_str()); }总结下调用顺序就是。Java_com_example_backtrackdemo_MainActivity_stringFromJNI -> func1 -> func2 -> func3 -> func4挑一个方法的汇编代码来看。​每个方法的开头和结尾都有这样5条指令，这种指令叫做栈平衡操作。众所周知，每个方法有属于自己的一块栈帧，在进入方法之后，首先要开辟出属于自己的栈空间，也就是。SUB SP,SP,#0x30这样就给自己开辟了 0x30 大小的一块栈空间。​然后保存上一个函数的信息，为了该方法结束的时候，可以跳转回上个函数。STP X29, X30, [SP, #0x20+var_s0]这样就把 X29 和 X30 寄存器保存在了当前的栈顶，按照 Arm64 的寄存器约定，X30 就是 LR，也就是函数返回时下一步要执行的指令地址。​然后把当前的栈顶信息又给了新的 X29 寄存器，所以 Arm64 的寄存器约定里，X29 就是 FP 寄存器，保存的是栈底信息。ADD X29, SP, #0x20这就是一个方法开始时做的事情。然后在方法结束的时候，恢复了上个方法的 X29 和 X30 寄存器信息。LDP X29, X30, [SP, #0x20 + var_s0]把自己的栈帧从堆栈中移除。ADD SP, SP, #0x30这样就完成了一个函数的堆栈操作，这块操作都是编译器自动实现的，至于分配给一个函数多大的栈空间，也是编译器根据函数中用的的栈大小来计算的，使用高级语言编程时无需感知这个过程。​细心的你可能已经发现了 X29 保存的当前函数的栈顶地址，然后在下个函数开始的时候又会被存到栈中保存，这样就形成了一个循环，你可以通过 X29 寄存器不断的向上回溯，这就是栈回溯的理论基础，用图表示的寄存器结构像下面这样。​基于.eh_frame的栈回溯这里不首先讲基于 FP 的栈回溯实现，而是说基于 .eh_frame（也叫Unwind）的 Unwind_backtrace。是因为 Android 的 C 库是 Google 家自己开发的 bionic，在 bionic 中，google 团队提供了官方的 backtrace 方法，Unwind_backtrace，https://github.com/gcc-mirror/gcc/blob/master/libgcc/unwind.inc，就是这个方案。​使用方法如下。// 1. 定义结构体存储unwind_backtrace返回的信息 struct BacktraceState { void **current; void **end; }; // 2. 定义callback方法，供unwind_backtrace回调 static _Unwind_Reason_Code unwindCallback(struct _Unwind_Context *context, void *arg) { BacktraceState *state = static_cast<BacktraceState *>(arg); uintptr_t pc; #ifdef HAVE_GETIPINFO int ip_before_insn = 0; pc = _Unwind_GetIPInfo (context, &ip_before_insn); #else pc = _Unwind_GetIP(context); #endif if (pc) { if (state->current == state->end) { return _URC_END_OF_STACK; } else { *state->current++ = reinterpret_cast<void *>(pc); } } return _URC_NO_REASON; } // 3. 调用_Unwind_Backtrace const size_t max = 32; void *buffer[max] = {0}; BacktraceState state = {buffer, buffer + max}; _Unwind_Backtrace(unwindCallback, &state); // 4. 使用_Unwind_Backtrace返回的信息 size_t count = state.current - buffer; for (size_t idx = 0; idx < count; ++idx) { const void *addr = buffer[idx]; // ... do something like dladdr(addr, &info) }Unwind_backtrace 和普通的基于 FP 的回溯有什么区别呢，Unwind_backtrace 是基于 .eh_frame 段解析的，接下来会简单的说下 .eh_frame 段的相关内容。但是关于 .eh_frame 段的详细历史https://www.freesion.com/article/30371059487/ 这篇文章讲的比较清楚。​编译器在构建的时候会生成 .eh_frame 段，这个段简单来说就是在通用寄存器变化时都记录了下来，记录成一个寄存器变化索引表，这样你不管执行到哪条指令，都可以根据这个表还原出寄存器的状态。表格是以非可读的字节码形式存储的，但是 readelf 已经做了解析工作。如果你用 readelf 去解析 so，可以看到这样的信息。​CFA 是栈基地址，后面是几个通用寄存器的恢复方法，ra 就是上一级函数的地址。​有了这个表，再根据当前的 PC 寄存器的值就可以恢复每一级函数的调用地址。以上面的 demo 为例，在 func4 的地方我们打个断点，看下 PC 寄存器的值 0x7a34b95150。需要注意的是这个 PC 寄存器的值是 so 加载到内存后实际的内存地址，需要减去加载到内存块的起始地址才是实际在 so 中的位置。起始地址怎么看很简单。​先查一下这个 app 的进程号。adb shell "ps | grep com.example.backtrackdemo" u0_a317 27476 841 5332892 104952 0 0 t com.example.backtrackdemo然后在 maps 里面看内存的分布。main_boost_switch map_files/ maps OnePlus8:/ # more /proc/27476/maps | grep "native-lib.so" 7a34b86000-7a34bb7000 r-xp 00000000 fc:09 32864 /data/app/com.example.backtrackdemo-JrcMGs7yb18P3a4WTWIZpA==/lib/arm64/libnative-lib.so 7a34bb7000-7a34bbb000 r--p 00030000 fc:09 32864 /data/app/com.example.backtrackdemo-JrcMGs7yb18P3a4WTWIZpA==/lib/arm64/libnative-lib.so 7a34bbb000-7a34bbc000 rw-p 00034000 fc:09 32864 /data/app/com.example.backtrackdemo-JrcMGs7yb18P3a4WTWIZpA==/lib/arm64/libnative-lib.so一般情况下第一个地址就是这个 so 在内存中的 base 地址（这里不考虑异常情况，在代码中计算 base 网上也可以查到很多示例代码），所以我们知道实际 PC 地址是 0x7a34b95150 - 0x7a34b86000 = 0xF150​接下来我们就在 .eh_frame 段中找到记录这个 PC 的块（也叫 FDE）。00000018 000000000000001c 0000001c FDE cie=00000000 pc=000000000000f11c..000000000000f16c LOC CFA x29 ra 000000000000f11c sp+0 u u 000000000000f128 x29+16 c-16 c-8可以看到在 f128 之后，ra 的值是 c-8，也就是 x29+16-8，调式器里打一下这个值。7a34b951c4。​正好和 lldb 打印的栈回溯中上一级函数的地址对应起来了。找到上一级 PC 后，我们可以继续回溯，上一级 PC 的实际值是 0x7a34b951c4-0x7a34b86000=0xf1c4，那找到对应的 FDE。00000038 000000000000001c 0000003c FDE cie=00000000 pc=000000000000f16c..000000000000f1d0 LOC CFA x29 ra 000000000000f16c sp+0 u u 000000000000f178 x29+16 c-16 c-8ra = c-8 = x29+16-8，.eh_frame 是个静态段，这里的 x29 是指的的当前栈帧的 x29 寄存器的值，那这个值怎么获取呢，在理论背景中提到，x29 寄存器其实就是 FP 寄存器，FP 寄存器是依次存储的，所以当前x29寄存器的值就是上一级函数的 x29 寄存器的地址，实际上 ra = c-8 = x29+16-8 = *x29+16-8。​这里回溯到上一级 PC 地址 7a34b95218，以此类推就可以回溯各级调用栈了。​说到这里你可能有个疑问，虽然我们有个 .eh_frame 在这里，但是好像也要通过 x29 寄存器向上回溯，其实不然，当编译器保存 x29 的值的时候，你可以通过 x29 进行回溯，当寄存器没有保存 x29 值的时候，会记录相应的 SP 寄存器的偏移。比如我们可以在编译选项中增加-fomit-frame-pointer。add_compile_options(-fomit-frame-pointer)可以优化掉 FP 寄存器，这个时候在看 .eh_frame 段就是以 SP 寄存器作为偏移标准了。00000018 0000000000000014 0000001c FDE cie=00000000 pc=000000000000f26c..000000000000f288 LOC CFA 000000000000f26c sp+0 000000000000f270 sp+16 00000030 0000000000000014 00000034 FDE cie=00000000 pc=000000000000f288..000000000000f43c LOC CFA ra 000000000000f288 sp+0 u 000000000000f290 sp+128 c-16 00000048 0000000000000014 0000004c FDE cie=00000000 pc=000000000000f43c..000000000000f510 LOC CFA ra 000000000000f43c sp+0 u 000000000000f444 sp+80 c-16 00000060 0000000000000014 00000064 FDE cie=00000000 pc=000000000000f510..000000000000f570 LOC CFA ra 000000000000f510 sp+0 u 000000000000f518 sp+48 c-16用 Unwind 还有一个好处是，它不仅可以做栈回溯，它可以恢复所有寄存器的值，这就是为什么 Google 的 bionic 顺便用它来做栈回溯的原因。​但是通过 Unwind 的实现原理我们知道，它依赖 .eh_frame 段，在 so 里时，一切正常，但是当这个方法在动态代码中，比如一个虚拟机的字节码(https://yuque.antfin.com/jiantaozhang.zjt/dvm)中，就失效了，因为动态代码根本没有将自己的信息编译进 .eh_frame 段中，这时候就还需要用老本行，基于 FP 寄存器的回溯。基于FP递归的栈回溯说起 FP 的递归回溯其实也不麻烦，甚至比 Unwind 更简单一些，你只需要拿到 FP 寄存器的值，这需要用一点内联汇编。void get_fp(unsigned long *fp) { #ifdef __aarch64__ __asm__ __volatile__ ( "mov %0, x29 \t\n" :"=r"(*fp)); #else __asm__ __volatile__ ( "mov %0, r7 \t\n" :"=r"(*fp)); #endif }然后一层层的进行遍历就行了size_t backtrace(FuncInfo * stack, size_t max) { unsigned long fp = 0; int depth = 0; do { if (stack == NULL) { break; } get_fp(&fp); if (fp == 0) { break; } for (depth = 0; (depth < max) && (0 != fp) && (0 != *(unsigned long *)fp) && (fp != *(unsigned long *)fp); ++depth) { stack[depth].pc = (void *)(*(unsigned long *)(fp + sizeof(unsigned long))); Dl_info info; if (!dladdr(stack[depth].pc, &info)) { break; } if (!info.dli_fname) { break; } if (info.dli_fname && strstr(info.dli_fname, "/data/app") == NULL) { break; } __android_log_print(ANDROID_LOG_INFO, "backtrace", "pc %p", stack[depth].pc); __android_log_print(ANDROID_LOG_INFO, "backtrace", "symbol %s", info.dli_sname); fp = *(unsigned long *)fp; } } while (false); return depth; }说到这，我们再来比较一下基于 FP 寄存器的回溯和基于 .eh_frame 段的回溯各自的优缺点。基于FP寄存器的回溯效率高不能穿过 JNI 和 OAT如果编译选项中优化掉了 FP 寄存器，则不能使用基于 .eh_frame 段的回溯解析复杂、效率低兼容性好Android 原生支持可以恢复所有通用寄存器的值腾讯有个开源项目 https://cloud.tencent.com/developer/article/1832287，优化了系统的 Unwind_backtrace 方案，只恢复 PC 寄存器的值，忽略其他寄存器，我也有兴趣在内部接入这个方案，有兴趣的小伙伴可以联系我。踩平的一些坑上面的代码可以正常运行，是因为我在坑里游了一会泳，首先第一个坑是这句代码。if (info.dli_fname && strstr(info.dli_fname, "/data/app") == NULL) { break; }为什么限制只在 app 自己的 so 中遍历的，因为 android 的系统库不遵循 FP 的规则，FP 存的不是上一级栈底的地址，这个通过汇编可以看出来。​art_quick_generic_jni_trampoline 将自己的 x29 和 pc 放在了 sp+0xd0 的地方，然后把 sp 给了 x29。​所以在 stringFromJNI 函数里面拿到的 x29 的值加上 0xd0 才是存 pc 的地方。​可以看出来，这里 x29 存的是 sp 的地址，所以如果想穿透系统函数，这里需要把 x29 的值加上 0xd0，拿到的值才是 pc（x30）的地址。​当然了，每一个函数栈帧的大小不一样，这里需要加的偏移也不一样，所以通过 FP 回溯遍历在这里会特别麻烦。当然我们一般没有需要回溯到系统函数的需求，所以遇到系统函数就直接返回了。​第二个坑，前面提过现在这个栈回溯的需求是在动态虚拟机的字节码里，所以不出意外，动态虚拟机的调用链中应该也有不遵循 FP 回溯标准的函数吧，看了一下，不出意外果然有。这个坑怎么解决的其实和上面对系统库函数的分析类似，总结一下就是看汇编代码，这个函数是个静态函数，栈帧固定是 0x70 大小，所以遇到这个函数的时候，就直接把上一级的 FP+0x70 跳过，去遍历下个函数。因为这种非标函数比较少，所以这个 workaround 是可行的。​总结以上就是这次调研栈回溯过程中学习的知识和解决的问题，记录一下。​ReferencesUNWIND 栈回溯详解 https://www.freesion.com/article/30371059487/探索Android平台ARM unwind技术-2 https://zhuanlan.zhihu.com/p/345878125介绍一种性能较好的 Android native unwind 技术 https://cloud.tencent.com/developer/article/1832287arm 栈帧/栈回溯/栈帧回溯 相关 #981 https://github.com/cisen/blog/issues/981自己动手实现arm函数栈帧回溯 https://blog.csdn.net/ce123_zhouwei/article/details/8580185arm与arm64调用栈 http://tangjj.blog.chinaunix.net/uid-29955651-id-4980319.htmlbacktrace.c https://opensource.apple.com/source/Libc/Libc-825.24/gen/backtrace.c.auto.htmlAndroid&iOS崩溃堆栈上报 https://www.cnblogs.com/songcf/p/4885468.html函数调用栈的获取原理分析 http://hutaow.com/blog/2013/10/15/dump-stack/

开发者学堂课程【JDK的选型、安装与配置:JDK 选型安装】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址:https://developer.aliyun.com/learning/course/52/detail/1021JDK 选型安装目录:​​一、JAVA 抽象层 1.JVM（JAVA 虚拟机） 2.JRE（JAVA 的执行环境） 3.JDK（开发工具包） 二、历史上的众多 JAVA 实现 三、“正统”Open JDK 四、Oracle JDK 生命周期 五、AdoptOpenJDK:JDK 发行的事实标准 六、JDK 的质量保证 七、JDK 选型小结 八、Java 运行环境的配置 1.下载 OpenJDK 发行版 2.解压安装 3.配置环境一、JAVA 抽象层1.JVM（JAVA 虚拟机）J​VM 有很多组件，最开始用户的代码是通过 BAD CODE 写成，然后被 CLASS LOADER 加载，加载完之后就是 JVM 可以识别的内部数据结构。BAD CODE 可以被执行，也定义了一些数据的类型。下面是 JAVA 的一些执行引擎。这些引擎通过 ATM 接口和最底下的操作系统进行交互。2.JRE（JAVA 的执行环境）JRE 和 JVM 几乎是一体的，但是 JRE 在组织上包括一些基础的类库，比如 java.net可以保护网络，java.io 可以保护文件，j.u.c 可以帮助构建并发的应用程序，这也是JAVA 流行的重要原因。 3. JDK（开发工具包）各种语言都有相应的开发工具包，JDK 就是 JAVA 的开发工具包，里面包含了开发工具。如果需要开发 JAVA 程序，则需要开发包里面拥有 JAVA 的编译器。二、历史上的众多 JAVA 实现历史上有众多 JDK，JAVA 定义了语言规范，使得业界百花齐放，只要遵循这个规范，那就是一个 JAVA 虚拟机。历史上出现过许多 JAVA 实现，比如 1996 年，SUN 公司提供了 Classic VM，不久后，SUN 公司在 1997 年推出了 Exact VM，特点是效率更高。之后在 1999 年，SUN 公司收购了 Hotspot 虚拟机，是当时世界上最好的虚拟机，在 1999 年，取代了 Sun 的 Classic VM 虚拟机，成为了默认的 JAVA 虚拟机。之后又出现了 JRockit 和 IBM J9 。但是最终，Hotspot 称为 JAVA 默认的虚拟机。三、“正统” Open JDKHotspot 是 OpenJDK 里面默认的 JAVA 虚拟机实现。OpenJDK 是由 JCP 这个组织去规划它的路线，进而实现它。在 OpenJDK 基础上加上 Oracle 特性就是可以在 Oracle 官网上下载下来的 Oracle JDK。然后第三方厂商也会基于 OpenJDK 去构建自己的构造，比如自己的发行版，例如亚马逊的 Corretto，Azul 的 Zulu，阿里巴巴也提供了 JAVA 发行版，在 OpenJDK的基础上加上阿里巴巴云原生特性，形成了阿里巴巴的 Dragonwell。四、Oracle JDK 生命周期使用 Oraacle 需要注意很多事情。Oracle JDK 有一个生命周期的限制。在 Oracle JDK 8月212 这个版本开始，它的授权形式从 Oracle Binary Code License 变成了 Oracle Technology Network License。简单来说，在生长环境使用 Oracle JDK 是要被收费的。下图描绘了 JDK 的生命周期形式。红色长条表示 Oracle JDK 的生命周期支持，看蓝色长条表示 Open JDK 的生命周期支持。对于普通用户来说，需要选择 Open JDK 的发行版，而不是去使用商业版的 Oracle JDK。 五、AdoptOpenJDK:JDK 发行的事实标准目前，整个业界标准是 AdoptOpenJDK 去主导 Open JDK 的发行，因为 Oracle 不做这个发行，自然需要一个第三方组织去发行 Open JDK。其中成员有 Amazon Corretto、IBM OpenJ9、SAP Machine、Alibaba Dragonwell。AdoptOpenJDK 影响是非常大的，比如在 Spring 的官网上下载 JDK 的话，它会首先推荐去下载一个 AdoptOpenJDK。下图是官网上长期的一个测试。六、JDK 的质量保证深挖一下测试是如何进行的，从源码构建出 JDK 的 Release image,它就是平时使用的 JAVA 命令。然后 image 需要通过 JTreg 测试，通过 TCK 的认证，只有经过完整测试之后，才是一个完整的 AdoptOpenJDK 的发行版。七、JDK 选型小结1.优先选择 OpenJDK2.Oracle 不再免费提供最新的 OpenJDK3.AdoptOpenJDK 下的 Dragonwell 是一个好的替代品 八、Java 运行环境的配置1.下载 OpenJDK 发行版2.解压安装3.配置环境4.HelloWorld

Steampunk is going all-in什么是 SAP ABAP Steampunk(蒸汽朋克)？Steampunk（又名 SAP BTP ABAP 环境）：提供一个 ABAP 平台，它不仅像今天一样是企业就绪(enterprise-readiness)的基准，而且也是云就绪的。 蒸汽朋克的主要属性是：(1) 平台和顶部解决方案之间的专用稳定公共接口，确保升级无故障(2) 用于云开发的企业就绪环境，包括新的 ABAP 语言版本和 ABAP RESTful 应用程序编程模型 (RAP)(3) 具有 BTP 集成、标准化系统更新和配置以及自动化操作的云就绪运行时环境(4) 我们当前客户群的云过渡路径，仔细平衡上述两种风险2020年之后，ABAP 蒸汽朋克已经支持多租户。这意味着我们的合作伙伴可以显着降低成本，他们现在可以在同一个 Steampunk 系统中为多个客户提供 SaaS 解决方案。对于 ABAP 内部人员：Steampunk 多租户架构基于 Client 字段，因此提供了消费者（租户）之间的完全隔离，每个额外消费者的成本最低。除此之外，蒸汽朋克带来了如此多的增强：针对云优化的改进型 ABAP 语言、对开发人员的更有效支持、为管理员提供更好的工具、用于 ERP 自定义代码的迁移工具、重用服务或为合作伙伴提供的可扩展性只是其中的一小部分。同时，SAP 蒸汽朋克团队正在致力于通过使用 Kubernetes 弹性扩展应用程序服务器、零停机更新、减少最小 HANA 内存大小（30GB 而不是 64GB）、高可用性和灾难恢复、更多数据中心和超大规模器来节省成本，仅举几例。无论用例如何，我们都为所有具有 ABAP 意识的客户和合作伙伴提供强大的云产品。今天，SAP BTP 上的 Steampunk 支持以下场景：(1) 客户使用 side-by-side 的方式，扩展他们的 ERP 应用程序（清洁核心计划，即 clean core initiative）(2) 向其客户提供 SaaS 应用程序的合作伙伴(3) 为 SAP 价目表开发 SAP 解决方案扩展的合作伙伴（例如 Vistex）(4) SAP 产品（例如公用事业市场通讯 - Market Communications for Utilities，或 SAP Master Data Governance, Cloud Edition）(5) SAP 自己的内部 ERP 扩展什么是嵌入式 ABAP 蒸汽朋克 - Embedded SteamPunk?Steampunk 是松散耦合的并行扩展或提供用 ABAP 编写的 SaaS 解决方案的合作伙伴的绝佳选择。这有点类似于在 NetWeaver 上并行运行的解决方案。关于扩展机制，On-Premises 系统（左下角）没有太大变化。但在云中，必须只提供云就绪扩展机制，在升级后不会出现问题。对于所有松散耦合的 ABAP 场景，解决方案是 BTP 上的 Steampunk（右上角），在平台和上面的层之间有一个稳定的公共接口（绿色）。并行扩展 ERP 核心非常适合许多用例。但并不适合所有人。考虑需要在正在扩展的应用程序附近运行的自定义代码。在同一上下文中，调用本地 API，例如，避免大量数据复制，或在同一逻辑工作单元（数据库 LUW）中运行。对于这些情况，S/4HANA Cloud 到目前为止仅提供关键用户可扩展性（上图左上角）。这虽然是一种强大的机制，允许字段扩展或自定义业务逻辑，但无法与开发人员级别的经典扩展可能性进行比较。在 S/4HANA Cloud 提供本地扩展样式当然不是一种选择，因为这种策略并不是云就绪，不是升级稳定的）。这就是我们引入嵌入式蒸汽朋克的原因：在内部，S/4HANA Cloud 和 Steampunk 无论如何都共享相同的 ABAP 平台代码行（标记为蓝色），而 Steampunk 是一种创新的领跑者。 因此，将 Steampunk 开发模型直接嵌入 S/4HANA Cloud 堆栈是合乎逻辑的下一步。 使用嵌入式蒸汽朋克开发的自定义扩展现在具有与蒸汽朋克云就绪和升级稳定相同的属性：仅使用稳定的公共接口无需修改 SAP 代码ABAP 语言和其他技术的限制使用限制使用系统功能使用 RAP 进行高效开发使用 ADT（ABAP 开发工具）使用嵌入式 Steampunk 开发扩展感觉就像在 BTP 上使用 Steampunk 开发一样。 还有一个重要的额外好处：嵌入式 Steampunk 扩展不仅可以调用更具技术性的 ABAP 平台接口（绿色），还可以调用包含业务功能（例如，CDS 视图，如 I_Product、 替换对表 MARA 或 RAP 外观的直接访问以创建采购订单）。 在 S/4HANA Cloud 中，自定义代码本身要么是自己的应用程序或服务，要么是使用众所周知的 BADI 技术通过公共扩展点实现的。如果您是一名 ABAP 开发人员，并且愿意熟悉 RAP、ADT 而非 SE80，或者是干净的 API 而不是自由式修改，那么嵌入式 Steampunk 会让您感到宾至如归。 您可以使用您已经知道的所有工具和流程。 这些都是 SAP 数以千万计的开发人员每天使用的相同工具和流程。Embedded Steampunk for S/4HANA on-premS/4HANA On-Prem 仍然允许经典扩展，缩短了从经典 ERP 世界的迁移路径，但留下了升级问题。借助本地 S/4HANA 中的嵌入式 Steampunk（下方左下角），我们希望支持将这些系统转换为更清洁的核心，并在 SAP 和扩展之间建立稳定的公共接口。当然，由于大量经典的自定义代码和缺少公共 SAP API 或扩展点，我们不能在一夜之间强制执行这样的举措。这就是为什么本地 ABAP 自定义代码现在可以设置一个标志，告诉 ABAP 编译器是允许经典代码还是强制执行严格的 Steampunk 检查。因此，本地 S/4 客户可以在 ABAP 类级别上自由选择：保持经典的扩展方法或重构它。毋庸置疑，重构使核心逐步变得更干净，减少升级问题并为未来迁移到云做好准备。Steampunk 开发环境在 BTP、S/4HANA Cloud 和 S/4HANA On-Prem 中完全相同。本地公共 S/4 业务接口（橙色）目前是使用云优先方法创建的，但也会随着时间的推移在本地 S/4 中增长。在我们看来，蒸汽朋克和嵌入式蒸汽朋克使从本地到混合再到云的漫长过渡期变得更加容易。并且两者都完全支持清洁核心战略。嵌入式 Steampunk 已经在 Sapphire 2021 上作为实验室预览版(lab preview ) 短暂宣布。我们从 S/4HANA Cloud 开始，目前正在通过早期采用者计划（仅限受邀者）收集第一批客户反馈，然后将其推广给所有客户。 请继续关注 SAP TechED 2021 的更多信息！

这是 Jerry 2021 年的第 46 篇文章，也是汪子熙公众号总共第 323 篇原创文章。Jerry 已经有很长一阵子没有打开工作电脑上的 SAP ABAP Development Tool 了。在用 Visual Studio Code 进行 Angular 开发马上快满一年的时间点上，为了做到喜新不厌旧，本文把 SAP ABAP Development Tool 一些提高工作效率的使用小技巧罗列出来。欢迎大家在留言区补充。关于 Jerry 之前分享过的 SAP ABAP Development Tool 使用技巧，请查阅这些文章：ABAP Development Tool 代码模板和其他一些实用技巧汇总给你的ABAP对象打上标签(Tag)ABAP开发环境终于支持以驼峰命名法自动格式化ABAP变量名了SAP官方发布的ABAP编程规范ABAP开发环境语法高亮的那些事儿不喜欢SAP GUI？那试试用Eclipse进行ABAP开发吧1. 快速打开 ABAP Development Tool 任意设置假设我想打开 ABAP Development Tool 和颜色 (color) 相关的设置，但是我记不住具体的设置路径了，没有关系，使用快捷键 Ctrl + 3：在输入框内输入 color，然后就能看到所有和 color 相关的设置。2. CDS view 数据的本地保存CDS view 数据预览之后，可以通过 Add filter 右边这个小图标，以不同的格式另存到本地以便进一步分析。3. 快速打开任意一个 ABAP 开发对象快捷键 Ctrl + Shift + A，在打开的弹出窗口里输入搜索条件，即可快速搜索并打开找到的对象。支持常用的搜索通配符。4. 在嵌入的弹出对话框查看对象明细例如我们想查看标准视图 /DMO/I_Travel_U 的明细，无需打开其视图本身。5. 在 ABAP 类方法实现的任意位置查看其参数定义SAPGUI 里能在编写 ABAP 类方法源代码实现时，随时查看其方法参数定义，这一点我很喜欢后续即将介绍的小技巧里，我们还能对 Alt + F2 显示的内容进行增强。6. 类似 Visual Studio Code 的 Quick Fix 功能我用了快一年的 Visual Studio Code 进行 Angular 开发了，真心喜欢其 Quick Fix 功能, 编译器能通过上下文，自动给出一些编译错误的解决方案。ABAP Development Tool 里也有类似功能。比如下面的例子，代码第25行，变量 lo_request 没有定义就直接使用，引起了一个编译错误。对自己编写的代码经常使用 ADT Quick Assistant, 多思考其提出的重构建议，有助于提升我们的代码质量。7. 添加代码注释想让你的方法能够像 Visual Studio Code 里显示的注释一样专业吗？在 SAP ABAP Development Tool 里当然也能做到。8. 让 ABAP 代码格式化工具支持驼峰风格(Camel Case)在 ABAP Formatter 设置里，将 Keep Camel Case Identifiers 前的勾打上即可。9. 更改 ABAP 关键字的颜色SAPGUI 里所有的 ABAP 关键字都只能设置为同一种颜色。而 ABAP Development Tool 里，能够为不同的关键字分别设置不同的颜色：Visual Studio Code 需要安装额外的扩展才能实现这个颜色更改需求，而 ADT 本身的设置就足以工作了，相当赞。如果需要整天面对 ABAP 代码，那么将其外观设置得五彩缤纷一点，或许也能让自己编程时，心情更加愉悦一些。10. ABAP Occurances以 Visual Studio Code 为例，假设我想查看名为 config 的属性在 Component 里所有的出现场景(Occurances), 需要 Ctrl + F 打开搜索框，输入 .config. 这样，代码中所有出现 .config 的位置，会被高亮显示。希望这些小技巧能够帮助提高大家使用 SAP ABAP Development Tool 的开发效率。Jerry 的 ABAP 专题Jerry的ABAP, Java和JavaScript乱炖ABAP开发人员未来应该学些什么Jerry 2017年的五一小长假：8种经典排序算法的ABAP实现Jerry的ABAP原创技术文章合集300行ABAP代码实现一个最简单的区块链原型使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数在SAP云平台的CloudFoundry环境下消费ABAP On-Premise OData服务ABAP vs Java， 蛙泳 vs 自由泳聊聊C语言和ABAP动手使用ABAP Channel开发一些小工具，提升日常工作效率我用ABAP做过的那些无聊的事情不喜欢SAP GUI？那试试用Eclipse进行ABAP开发吧使用Visual Studio Code编写和激活ABAP代码你的ABAP程序给佛祖开过光么？来试试Jerry这个小技巧在SAP云平台ABAP编程环境上编写第一段ABAP程序SAP官方发布的ABAP编程规范ABAP Code Inspector那些隐藏的功能，您都知道吗？还在用ABAP进行SAP产品的二次开发？来了解下这种全新的二次开发理念吧ABAP Netweaver体内的那些寄生式编程语言从SAP社区上的一篇博客开始，聊聊SAP产品命名背后的那份情怀云端的ABAP Restful服务开发如何在SAP云平台ABAP编程环境里把CDS view暴露成OData服务使用abapGit在ABAP On-Premises系统和SAP云平台ABAP环境之间进行代码传输30分钟用Restful ABAP Programming模型开发一个支持增删改查的Fiori应用Jerry带您了解Restful ABAP Programming模型系列之二：Action和Validation的实现Jerry带您了解Restful ABAP Programming模型系列之三：云端ABAP应用调试SAP云平台上的ABAP编程环境里如何消费第三方服务ABAP开发者上云的时候到了 - 现在大家可以免费使用SAP云平台ABAP环境的试用版了学而不思则罔 - SAP云平台ABAP编程环境的由来和适用场景SAP云平台里的三叉戟应用如何基于Restful ABAP Programming模型开发并部署一个支持增删改查的Fiori应用SAP 2019 TechEd Key Note解读：云时代下SAP从业人员如何做二次开发？有哪些ABAP关键字和语法，到了ABAP云环境上就没办法用了？ABAP开发环境终于支持以驼峰命名法自动格式化ABAP变量名了利用ABAP 740的新关键字REDUCE完成一个实际工作任务一段让人瑟瑟发抖的ABAP代码昨日万圣节ABAP怪兽级代码谜团，公布答案啦介绍一种在ABAP内核态进行内表高效拷贝的方法使用SAP Cloud Application Programming模型开发OData的一个实际例子当ABAP遇见普罗米修斯使用ABAP绘制可伸缩矢量图ABAP开发环境语法高亮的那些事儿SAP错误消息调试之七种武器：让所有的错误消息都能被定位使用ABAP操作Excel的几种方法SAP GUI里的收藏夹事务码管理工具SAP GUI和Windows注册表有了Debug权限就能干坏事？小心了，你的一举一动尽在系统监控中ABAP CCDEF, CCIMP, CCMAC, CCAU, CMXXX这些东东是什么鬼实现ABAP条件断点的三种方式使用SAT跟踪监控从浏览器打开的SAP应用的性能和调用栈一个13年ABAP老兵的建议：了解这些基础知识，对ABAP开发有百利而无一害SAP ABAP Netweaver容器化, 不可能完成的任务吗？SAP产品增强技术回顾SAP API开发方法大全浅谈Java和SAP ABAP的静态代理和动态代理，以及ABAP面向切面编程的尝试SAP ABAP应用服务器的HTTP响应状态码(Status Code)SAP ABAP里存在Java List这种集合工具类么？CL_OBJECT_COLLECTION了解一下ABAP面试题系列：写一组会出现死锁(Deadlock)的ABAP程序SAP ABAP Netweaver服务器的标准登录方式讲解SAP ABAP关键字语法图和ABAP代码自动生成工具Code ComposerSAP ABAP SM50的另类用途 - ABAP工作进程对数据库表读取操作的检测关于SAP ABAP字符变量和字符串变量字符个数的一个知识点，和一个血案SAP ABAP一组关键字 IS BOUND, IS NOT INITIAL和IS ASSIGNED的用法辨析SAP ABAP和Java里的弱引用(WeakReference)和软引用(SoftReference)SAP AMDP介绍 - ABAP托管的HANA数据库过程给你的ABAP对象打上标签(Tag)历史上的今天：编程语言中null引用的十亿美元错误ABAP Development Tool 代码模板和其他一些实用技巧汇总

Theano 是一个 Python 库，可用于定义、优化和计算数学表达式，特别是多维数组（numpy.ndarray）。在解决包含大量数据问题的时候，使用 Theano 编程可以获得比手写 C 语言实现更快的速度。通过新近的 GPU 加速，Theano 可以比基于 CPU 计算的 C 语言快上好几个数量级。Theano 结合了计算机代数系统（computer algebra system/CAS）和优化编译器。它还可以为多种数学运算生成定制的 C 语言代码。对于包含重复计算复杂数学表达式的任务而言，计算速度很重要，因此这种 CAS 和优化编译器的组合是很有用的。对于需要将每一种不同的数学表达式都计算一遍的情况，Theano 可以最小化编译/解析的计算量，但仍然会给出如自动微分那样的符号特征。Theano 由蒙特利尔大学 LISA 实验室所编写，用来支持高效机器学习算法。其名字来自于一位希腊数学家，她可能也是毕达哥拉斯的妻子。以下为 Theano GitHub 项目的开发者与维护者，可以看到谷歌研究科学家 Ian Goodfellow 也是其中之一：近 10 年来，Theano 一共有 322 位贡献者对该项目做出杰出的贡献。截至到目前，该项目共有 554 个关注（watch）、6964 个收藏（star）和 2300 次复制（fork）。如今，身为主流框架之一的 Theano 面临「死亡」。在 Yoshua Bengio 的邮件被贴出之后，Reddit、HackNews 上已经一片热议。虽是一个开源框架，缺少了固定开发与维护者，在 TensorFlow、MXNet、Caffe、CNTK 等深度学习框架竞争下必然丧失优势。对此，很多 Theano 用户都大感惋惜。如 bbsome 在 Reddit 上说：「我是 Theano 的忠实用户，我常常大力提倡使用它进行研究，我最近在一些案例上观察到它的性能要比 TensorFlow 更好，不幸的是，我们没有那么多基准测试。虽然 Theano 在长时间内并不会消失，但主流扩展包将永远得不到更新了。」以下为 Yoshua Bengio 发出的邮件，说明了 Theano 即将在未来几周内终止开发：亲爱的用户和开发者：十年一路走来，我们遗憾地宣布 Theano 在 1.0 版本之后，即将在未来的几周内终止开发；我们将继续最低程度的维护从而保证它足够运行一年，但不会再更新功能。随后，Theano 作为一款开源软件继续可用，但是 MILA 不再维护它。支持深度学习研究的软件生态系统快速进化，且状态良好：开源软件成为规范，大量框架并存，满足着从探索全新想法到将其部署实现的全部需求；并且在激烈竞争中不同巨头支持着不同的软件堆栈。我们为多年以来 Theano 的创新深感自豪，并且其创新正被其他框架继承和优化。比如，把模型表达为数学表达式、重写计算图以获得更优性能和内存使用、GPU 上的透明执行、更高阶的自动微分，正在全部成为主流。在这一背景下，我们认为继续维护 Theano 不再是推动全新研究与应用的最佳方式。即使来自学界、业界的贡献与支持不断增加，维持陈旧的代码库并保持竞争已经成为了创新的阻碍。MILA 仍然会致力于支持学者们实现最新发明（有时甚至是异想天开的想法），我们仍会通过其它方式遵循这一理念继续前进，在其他项目中为开源社区做出更多贡献。感谢所有一直支持 Theano 的朋友们，是你们的持续努力让这一框架不断完善。 -- Yoshua Bengio

这是Jerry 2021年的第 12 篇文章，也是汪子熙公众号总共第 283 篇原创文章。今天是2021年1月20日，看看历史上的今天都发生了什么。2004年1月20日，第一个公开版本的Scala发布。Scala是一种采用静态类型系统的编译型语言，具有很强的可扩展性(Scalability)，这也是其名称的由来。Scala设计初衷是集成面向对象编程和函数式编程的各种特性，运行于JVM平台上，并兼容已有的Java程序。Jerry没有在SAP标准产品开发中使用过Scala，只是完成2015年公司一个内部培训布置的课程作业中，使用Scala在Spark上开发了一个最简单的demo：统计海量英文图书里，计算出使用频率最高的十大单词。Spark是一个使用Scala编程语言实现的专为大规模数据处理而设计的快速通用的计算引擎。本文不会讨论Spark，而是从Scala语言里，下图第11行的注解@tailrec谈起：尾递归(Tail Recursion).每个程序员对递归的概念都耳熟能详，那什么是尾递归呢？顾名思义，如果一个函数中递归形式的调用，出现在函数的末尾，且除了该递归调用外，不包含其他的运算操作，则我们称该递归函数是尾递归函数。本文用阶乘算法来介绍尾递归的概念。下图红色区域内是阶乘算法的常规递归实现，蓝色区域是阶乘算法的尾递归实现版本。在常规递归算法的末尾，第8行语句(绿色)，除了递归调用factorial函数外，还包含一个同n的乘法操作，所以整个函数factorial不能算作尾递归函数。而尾递归版本中，第14行函数末尾(黄色)，仅仅包含函数本身的递归调用，所以整个函数tailFactorial是一个尾递归函数。尾递归函数存在的意义是什么呢？要回答这个问题，我们可以先在单步调试模式下，观察常规递归函数的执行过程。我们首先使用常规递归函数，计算5的阶乘。输入参数n为5，执行到第7行，5的阶乘等于5乘以4的阶乘。单步调试进去，输入参数n = 5, 进入第7行，准备执行 5 * factorial(4) .注意观察下图的Call Stack列表，此时我们已经有两个factorial函数的调用栈帧了。什么是栈帧？复习一下大学计算机原理学到的知识：在函数执行过程中，每一个函数调用都会把当前函数的调用信息和内部变量保存在栈里面，称为一个栈帧(Stack Frame).其中下图序号为1的栈帧，保存了n = 5的计算上下文；序号为2的栈帧即当前最顶层的栈帧，保存了n = 4的计算上下文。因为只有当n = 1时递归才会结束，而当前n = 4，所以继续单步调试第7行：又生成了一个n = 3的栈帧：n = 2：终于我们来到了n = 1的上下文。看下图Call Stack里的栈帧列表，最顶层的栈帧代表当前n = 1的计算上下文。此时我们已经知道n = 1的阶乘结果如何计算了，即为1本身。第5行代码返回1的阶乘计算结果1，这行语句返回之后，当前序号为5的栈帧就会被销毁，即将回到下一层序号为4的栈帧去。此时只剩4个栈帧了，最顶层代表n = 2的栈帧。因为现在1的阶乘结果已经出来了，所以2的阶乘结果也能计算了，为2乘以1.2的阶乘返回后，现在只剩3个栈帧，最顶层为n = 3的计算上下文。3的阶乘也能计算了，为3乘以前一个栈帧返回的计算结果，即2的阶乘结果，所以最后为3 × 2 = 6. 如下图所示：4的阶乘计算，此时只剩两个栈帧：5的计算结果，回到最初最先被压到堆栈底部的n = 5的栈帧。计算完毕，5的阶乘为120.是不是体现出了《数据结构》教科书上关于栈“先进后出”的工作原理？下面再来看看用尾递归实现的阶乘。下图第20行语句是以尾递归方式计算5的阶乘入口，调用尾递归函数tailFactorial，注意函数的第二个输入参数total，这个参数用于存储当前阶乘的计算结果。这个尾递归函数的结束条件是，当第一个输入参数n为1时，就把第二个输入参数的值，作为阶乘运算的最终结果返回。第二个参数实际上存放的，是当前递归调用的阶乘计算结果。当n大于1时，递归尚未满足退出条件，此时首先将n和当前的阶乘计算结果(变量total)相乘，将乘积作为第二个输入参数，传递到下一层递归调用的栈帧中去。下图是tailFactorial函数内部，即将进入第一轮递归调用的栈帧：第一轮递归调用的栈帧内部，序号为2.注意，此时序号为1的栈帧已经完全不再需要了，因为我们继续进行递归调用的所需信息，都已经包含在第16行tailFactorial调用的两个输入参数里了，此时n为上一层递归调用传入的5 - 1 = 4，total为上一轮传入的5 × 1 = 5. 进行下一轮递归调用，两个输入参数的值分别是4 - 1 = 3和4 * 5 = 20.进入第三层递归调用，此时输入参数 n = 3，total = 20，均为上一层调用传入。注意，下图标号为1和2的两个栈帧，实际上不再需要了，因为要继续进行递归调用的所有输入信息，都已经存储在标号为3的栈帧里了：n = 2， total = 60，同理，标号为1，2，3的栈帧都不再需要了。n = 1，total = 120，终于计算结束了！这就是5的阶乘，如何通过尾递归的方式计算出来的全过程。我们在标号为5的栈帧里得到了最终的结果，而此时虽然栈帧1～4还存在，但实际上已经毫无用处了。因为按照尾递归版本的阶乘实现，每一轮阶乘的递归计算结果，已经通过第二个参数total保存了下来，因此没有必要再用一个完整的栈帧，去保存当前这轮递归计算的函数调用上下文了。这就引出了所谓“尾递归优化”的概念：When a compiler detects a call that is tail recursive, it overwrites the current activation record instead of pushing a new one onto the stack. The compiler can do this because the recursive call is the last statement to be executed in the current activation; thus, there is nothing left to do in the activation when the call returns. Consequently, there is no reason to keep the current activation around. By replacing the current activation record instead of stacking another one on top of it, stack usage is greatly reduced, which leads to better performance in practice. Thus, we should make recursive functions tail recursive whenever we can.https://www.oreilly.com/library/view/mastering-algorithms-with/1565924533/ch03s02.html上述文字大意如下：当(C语言)编译器检测到尾递归调用时，并不会创建新的栈帧并压入栈中，而是用新的栈帧覆盖掉当前处于激活状态的栈帧。编译器之所以能够这样做，是因为尾递归函数里，递归调用是当前栈帧里最后一个需要执行的函数调用。被覆盖掉的栈帧本身毫无用处，不需要再保留。采用栈帧覆盖，而不是新建栈帧的方式，极大程度上减少了栈帧的个数，提高了递归函数的执行性能。因此，应该尽可能地去尝试使用尾递归方式实现递归函数。一个实际的性能比较例子：计算20的阶乘，二者的性能有巨大差异：普通递归实现需要10毫秒，而尾递归实现仅仅需要不到1毫秒的时间。注意：一个递归函数能否用尾递归方式实现，和它能否享受运行时的尾递归优化，二者不是一回事，后者需要编译器的支持。应用开发人员通过Scala提供的@tailrec注解，告诉编译器，对注解修饰的方法进行尾递归优化：如果优化失败，或者被修饰的方法根本就不是一个尾递归函数，则编译器报错：could not optimize @tailrec annotated method fibonacci: it contains a recursive call not in tail position用ABAP实现尾递归版本的阶乘运算：至于ABAP编译器能否支持尾递归优化？我没有研究过，我只是觉得，尾递归优化并不能算是ABAP编译器必须实现的需求之一。希望本文能帮助大家对尾递归优化这个概念有一个最基本的认识，感谢阅读。

通过类型断言这种方式可以告诉编译器，“相信我，我知道自己在干什么”。 类型断言好比其它语言里的类型转换，但是不进行特殊的数据检查和解构。 它没有运行时的影响，只是在编译阶段起作用。 TypeScript会假设开发人员已经进行了必须的检查。类型断言有两种形式。 其一是“尖括号”语法：let someValue: any = "this is a string";let strLength: number = (someValue).length;第二种形式是as语法：let someValue: any = "this is a string";let strLength: number = (someValue as string).length;两种方式等价，但是在TypeScript里使用JSX时，只有 as语法断言是被允许的。

2.2 初识Java 面向对象编程思想把所有的有形或无形的事物都看作对象，并给对象赋予相应的属性和行为，建立对象之间的联系，使程序员更加立体、形象地解决编程领域的问题。面向对象语言的忠实代表是Java 语言，它是一门富有生命力的语言，在最受欢迎的语言排行榜上，多年位居第一。Java 语言是1995 年由Sun 公司首次发布的。次年Java 开发工具包发布，即Java Development Kit，简称JDK1.0，这是Java 发展的一个重要里程碑，标志着Java 成为一门独立的成熟语言。随后，Sun 公司再接再厉发布了Just-in-time 编译器，简称JIT，不断进步的JIT 技术使Java 的执行速度接近甚至超过其他高级语言。 JDK 随着时代不断往前发展。在众多版本中，最具划时代影响力的版本是JDK5，项目代号Tiger。Doug Lea 推出的并发包，使Java 如虎添翼，成为工业级语言，在企业服务端得到极为广泛的应用。随着后续版本的陆续推出，Java 的发展与时俱进，推出了diamond 语法、函数式、模块化、var 类型推断等新特性。最新的JDK 版本是JDK11。 JRE（Java Runtime Environment）即Java 运行环境，包括JVM、核心类库、核心配置工具等。其中JVM（Java Virtual Machine）即Java 虚拟机，它是整个Java 体系的底层支撑平台，把源文件编译成平台无关的字节码文件，屏蔽了Java 源代码与具体平台相关的信息，所以Java 源代码不需要额外修改即可跨平台运行。JVM 不仅支撑着Java 语言，还包括Kotlin、Scala、Python 等其他流行语言。其中Kotlin 是Jetbrains 开发的跨平台语言，其语法简洁、类型安全，可以编译成字节码运行在JVM上，与Java 语言非常方便地进行混合编程。1999 年，Sun 公司发布公开版本的HotSpot，它是当前主流的Java 虚拟机。2006 年，在JavaOne 大会上开源相关核心技术，启动OpenJDK 项目，逐步形成了活跃的OpenJDK 社区。在社区的带动下，Java 生态也随之繁荣，包括AJDK、Spring、Hadoop、Dubbo、JStorm、RocketMQ 等Java 相关解决方案，极大地提升了Java 语言的生产效率。 Java 语言拥有跨平台、分布式、多线程、健壮性等特点，是当下比较主流的高级编程语言。它的类库非常丰富、功能强大、简单易用，对开发者友好，不仅吸收了C++ 的优点，还摒弃了其难以掌控的多继承、指针等概念。Java 比较好地实现了面向对象理论，允许开发工程师以优雅的思维方式处理复杂的编程场景。现在我们简要回顾和总结一下从JDK5 到JDK11 的重要类、特性和重大改变。 JDK5 新特性：foreach 迭代方式、可变参数、枚举、自动拆装箱、泛型、注解等重要特性。 JDK6 新特性：Desktop 类和SystemTray 类、使用Compiler API、轻量级HTTPServer API、对脚本语言的支持、Common Annotations 等重要特性。 JDK7 新特性：Switch 支持字符串作为匹配条件、泛型类型自动推断、try-withresources资源关闭技巧、Objects 工具类、ForkJoinPool 等重要类与特性。 JDK8 新特性：接口的默认方法实现与静态方法、Lambda 表达式、函数式接口、方法与构造函数引用、新的日期与时间API、流式处理等重要特性。 JDK9 新特性：Jigsaw 模块化项目、简化进程API、轻量级JSON API、钱和货币的API、进程改善和锁机制优化、代码分段缓存等重要特性。 JDK10 新特性：局部变量的类型推断、改进GC 和内存管理、线程本地握手、备用内存设备上的堆分配等重要特性。 JDK11 新特性：JDK11 于2018 年9 月与《码出高效：Java 开发手册》同期发布，JDK11 中删除了Java EE 和 CORBA 模块，增加基于嵌套的访问控制，支持动态类文件常量，改进 Aarch64 内联函数，提供实验性质的可扩展的低延迟垃圾收集器ZGC等重要特性。 JDK12 新特性：Shenandoah 低暂停时间的GC、Switch 表达式功能增强、G1 收集器的优化。