CLR简介(四)

作者: 懿民 | 来源:发表于2016-04-04 22:18 被阅读124次

    内存和类型安全

    GC一个不怎么明显但是影响深远的功能就是内存安全。内存安全的意思很简单:只有程序只访问其分配(且没有被释放)的内存就是内存安全的。这意味着你不会有指向任意位置(精确来说就是过早释放的内存)的“野”(悬着的)指针。内存安全当然是我们希望所有程序都有的功能。野指针一般都是bug,而且跟踪它们相当困难。

    GC 必须 保障内存安全

    你可以很快看到GC对于内存安全的好处,因为其移除了用户过早释放内存(也就无法访问到没有正确分配的内存)的可能性。但另一个不怎么明显的因素是,如果你需要保证内存安全(即让程序员 不可能 创建一个内存不安全的程序),在实际操作中无法避免垃圾回收器。这是因为通常程序都需要(动态)内存分配系统,而这样对象的生命周期是任意的(与栈分配或者静态分配的内存不同,它们都是高度遵守分配协议的)。在这样不受控的环境下,通过分析程序来预测某个显式释放内存语句是否正确是不可能的。实际上,唯一判断释放语句是否正确只能在运行时做。这正是GC所做的事情(通过检查内存是否仍然有效)。因此,对于任何一个需要堆分配内存的程序来说,如果要保证内存安全,那必须使用GC。

    虽然GC是保障内存安全的必要手段,但还是不够。GC无法阻止程序在数组里做越界索引或者在对象的结尾之后访问字段(可以通过对象基址和偏移量计算字段的地址做到)。当然,如果我们防范了这些情形,那么我们的确使程序员无法创建内存不安全的程序。

    虽然 [通用中间语言]cil-spec 提供了存取任意内存位置的指令(即违背了内存安全原则),但它也有下列内存安全的指令集,并且CLR强烈建议使用它们:

    1. 字段访问指令集(LDFLD, STFLD, LDFLDA),根据名字读写字段地址。
    2. 数组访问指令集(LDELEM, STELEM, LDELEMA),根据索引读写一个数组元素地址。所有数组都带有指示其长度的标签,它用来在每次存取时做越界检查。

    通过在用户代码中使用这些指令集,而不是底层(且不安全的)内存读写 指令集,还可以规避其他不安全 [CIL][cil-spec] 的操作(如那些允许跳转到任意且可能是非法的地址),这些都是构建一个内存安全系统所必须的。但CLR不只做这个,它支持更严谨的规则:类型安全。

    类型安全是指每次内存分配都跟一个类型关联。所有操作内存的指令从理念上都与类型关联。类型安全要求读写指定内存只能使用与其关联的类型有效的指令集。这不仅保障了内存安全(没有野指针),也对每个类型加了一层额外的保护。

    这些类型相关的保障中有一个重要的性质就是类型的可见性要求(特别是对于字段来说)也被强制保证了。因此,如果一个字段被声明为私有(即只能被类型本身定义的函数可见),那么这个私密性要求会被所有类型安全的代码所遵守。比如说,某个类可能定义了一个名为count的字段来记录其名为table的集合里的元素个数。假设table和count字段都是私有的,而且只有更新这两个字段的代码同时更新两个,那么table集合里元素的个数和count字段的值同步这一点有了强有力的保证。无论是否了解类型安全,程序员都是使用类型安全的概念来推理程序逻辑的。CLR将类型安全从编程语言/编译器之间的简单约定,上升到可以在运行时遵守的规范了。

    可验证代码 - 强制内存和类型安全

    从理念上来说,为了保证类型安全,程序执行的每个指令都需要检查其是否符合内存关联的类型要求。虽然可以在运行时做这个检查,但性能会非常慢。所以CLR采用 [CIL][cil-spec] 验证的概念,即根据[CIL][cil-spec] 静态分析程序来确认大部分指令集是类型安全的。运行时只用来补充静态分析不能检查的地方。实际上,运行时的检查次数很少。它们包括下面这些指令:

    1. 将一个基类的指针强制转换为派生类型(反过来的转换可以放在静态分析里)。
    2. 数组越界检查(如同内存安全一样的道理)。
    3. 将指针数组里的元素替换成一个新(指针)值。这点是因为CLR数组的自由转换规则(在后文分析)。

    这些检查对CLR提了如下这些要求:

    1. GC里所有的内存都要关联类型(这样强制转换操作才能实现)。类型信息必须对运行时可见,而且要丰富到可以判断强制转换是否有效(即运行时需要知道类型的继承层次)。实际上,每个对象在GC堆的第一个字段就指向关联类型在运行时的数据结构对象。
    2. 所有的数组都必须包含其大小(用来做越界检查)。
    3. 数组必须知道其元素的完整类型信息。

    幸运的是,有些开销很大的要求(给堆上的内存打标签)也是支持垃圾回收所必要的(GC需要知道正在扫描的对象所有字段信息),因此支持类型安全的额外成本实际上不高。

    因此,按照[CIL][cil-spec]验证代码加上少量的运行时检查,CLR可以保证类型安全(和内存安全)。尽管如此,在编程弹性上,额外的安全带来严格的代价。CLR有直接的内存读写指令,为了保证代码可验证性,这些指令的使用范围很有限。如所有的指针运行都会使代码无法通过验证,因此很多C和C++的典型用法都不能在要通过验证的代码里使用;你必须使用数组。虽然这样让编码有点不舒服,但也不是很差(数组也很有用),而且好处是现成的(更少的“诡异”的bug)。

    CLR强烈建议使用可验证的,类型安全的代码。即使这样,有时还是要用到无法验证的代码(主要是跟非托管代码交互)。CLR运行这样,但是最佳实践是尽量限制(类型)不安全的代码的使用。一般的程序只有极少部分的不安全代码,而其它的是类型安全代码。

    相关文章

      网友评论

        本文标题:CLR简介(四)

        本文链接:https://www.haomeiwen.com/subject/hqqplttx.html