Java基础重难点

1、值传递和引用传递

传值的方式传引用。 或者说传值的方式传地址。
你这个问题其实很简单。要搞清楚这个问题，要明白：堆 和 栈。引用是保存在栈上，对象是保存在堆中。引用指向堆上的对象，也就是说引用的值为对象在栈上的内存地址。那么你修改引用时改的是引用的值，也就是让引用指向其它对象。那么应该怎么修改堆上的对象呢？首先你得访问到堆上的对象吧？如何访问到它呢？在C/C++中是通过指针运算符 *p 来访问到指针p指向的堆上的对象的，然后再修改它。那么Java中没有指针运算符，那么怎么办呢？Java中是通过点操作符，也就是 list.add中的那个点，表示先访问到list这个引用指向的对象，然后让该对象调用 add 方法，从而修改了list指向的堆上的对象。所以当你单独修改 list = xxx;时你修改的是引用，让list引用指向其它对象，而没有修改 list 引用指向的对象，因为你根本就没有访问到堆上的对象，你怎么修改它呢？
所以：要修改堆上的对象，你要先访问到它，不然你就不能修改它。访问堆上的对象的方法就是 . 点操作符。

2、同步、异步、阻塞、非阻塞

同步和异步关注的是消息通信机制 (synchronous communication/ asynchronous communication)。

所谓同步，就是在发出一个调用时，在没有得到结果之前，该调用就不返回。但是一旦调用返回，就得到返回值了。

换句话说，就是由调用者主动等待这个调用的结果。

而异步则是相反，调用在发出之后，这个调用就直接返回了，所以没有返回结果。换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。而是在调用发出后，被调用者通过状态、通知来通知调用者，或通过回调函数处理这个调用。

阻塞和非阻塞关注的是程序在等待调用结果（消息，返回值）时的状态.

阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。

3、概括的解释下线程的几种可用状态

1. 新建( new )：新创建了一个线程对象。

2. 可运行( runnable )：线程对象创建后，其他线程(比如 main 线程）调用了该对象 的 start ()方法。该状态的线程位于可运行线程池中，等待被线程调度选中，获 取 cpu 的使用权 。

3. 运行( running )：可运行状态( runnable )的线程获得了 cpu 时间片（ timeslice ） ，执行程序代码。

4. 阻塞( block )：阻塞状态是指线程因为某种原因放弃了 cpu 使用权，也即让出了 cpu timeslice ，暂时停止运行。直到线程进入可运行( runnable )状态，才有 机会再次获得 cpu timeslice 转到运行( running )状态。阻塞的情况分三种：

   (一). 等待阻塞：运行( running )的线程执行 o . wait ()方法， JVM 会把该线程放 入等待队列( waitting queue )中。

   (二). 同步阻塞：运行( running )的线程在获取对象的同步锁时，若该同步锁 被别的线程占用，则 JVM 会把该线程放入锁池( lock pool )中。

   (三). 其他阻塞: 运行( running )的线程执行 Thread . sleep ( long ms )或 t . join ()方法，或者发出了 I / O 请求时， JVM 会把该线程置为阻塞状态。当 sleep ()状态超时、 join ()等待线程终止或者超时、或者 I / O 处理完毕时，线程重新转入可运行( runnable )状态。

5. 死亡( dead )：线程 run ()、 main () 方法执行结束，或者因异常退出了 run ()方法，则该线程结束生命周期。死亡的线程不可再次复生。

4、多线程产生死锁需要四个条件

互斥条件：一个资源每次只能被一个进程使用。

保持和请求条件：一个进程因请求资源而阻塞时，对已获得资源保持不放。

不可剥夺：进程已获得资源，在未使用完成前，不能被剥夺。

循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

5、快速失败(fail-fast)和安全失败(fail-safe)的区别

一、快速失败（fail—fast）

在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出 Concurrent Modification Exception。

原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变 modCount 的值。每当迭代器使用 hashNext()/next() 遍历下一个元素之前，都会检测 modCount 变量是否为 expectedmodCount 值，是的话就返回遍历；否则抛出异常，终止遍历。

注意：这里异常的抛出条件是检测到 modCount != expectedmodCount 这个条件。如果集合发生变化时修改 modCount 值刚好又设置为了 expectedmodCount 值，则异常不会抛出。因此，不能依赖于这个异常是否抛出而进行并发操作的编程，这个异常只建议用于检测并发修改的 bug。

场景：java.util 包下的集合类都是快速失败的，不能在多线程下发生并发修改（迭代过程中被修改）。

二、安全失败（fail—safe）

采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。

原理：由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发 Concurrent Modification Exception。

缺点：基于拷贝内容的优点是避免了 Concurrent Modification Exception，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。

场景：java.util.concurrent 包下的容器都是安全失败，可以在多线程下并发使用，并发修改。

6、Comparable和Comparator接口

Comparable & Comparator 都是用来实现集合中元素的比较、排序的，只是 Comparable 是在集合内部定义的方法实现的排序，Comparator 是在集合外部实现的排序，所以如想实现排序，就需要在集合外定义 Comparator 接口的方法或在集合内实现 Comparable 接口的方法。

Comparator位于包java.util下，而Comparable位于包 java.lang下 ，Comparable 是一个对象本身就已经支持自比较所需要实现的接口（如 String、Integer 自己就可以完成比较大小操作，已经实现了Comparable接口） 自定义的类要在加入list容器中后能够排序，可以实现Comparable接口，在用Collections类的sort方法排序时，如果不指定Comparator，那么就以自然顺序排序， 这里的自然顺序就是实现Comparable接口设定的排序方式。

而 Comparator 是一个专用的比较器，当这个对象不支持自比较或者自比较函数不能满足你的要求时，你可以写一个比较器来完成两个对象之间大小的比较。 可以说一个是自已完成比较，一个是外部程序实现比较的差别而已。 用 Comparator 是策略模式（strategy design pattern），就是不改变对象自身，而用一个策略对象（strategy object）来改变它的行为。 比如：你想对整数采用绝对值大小来排序，Integer 是不符合要求的，你不需要去修改 Integer 类（实际上你也不能这么做）去改变它的排序行为，只要使用一个实现了 Comparator 接口的对象来实现控制它的排序就行了。

两者的比较

comparable接口：

• 优点：对于单元素集合可以实现直接排序
• 缺点：对于多元素排序，排序依据是固定不可更改的。（元素内部只能实现一次compareTo方法）

comparator接口：

• 元素的排序依据时刻变的，所以可以通过定义多个外部类的方式来实现不同的排序。使用时按照需求选取。
• 创建外部类的代价太大。

//在内部实现comparable接口，指定排序依据
class Student implements Comparable<Student> {
    private int age;
    private String name;
    public int getAge() { return age; }
    public String getName() { return name; }
    public void setName(String name) { this.name = name; }
    @Override
    public int compareTo(Student stu) {
        return this.getName().compareTo(stu.getName());//定义成升序
    }
}
//在外部实现comparator接口，构建自己的排序实现类，指定排序依据
class StudentSortWithAge implements Comparator<Student> {
    @Override
    public int compare(Student o1, Student o2) {
        return Integer.compare(o1.getAge(), o2.getAge());
    }
}

7、JVM方法区

方法区（线程共享）用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。对这块区域进行垃圾回收的主要目标是对常量池的回收和对类的卸载，但是一般比较难实现。JDK1.7把它当成永久代来进行垃圾回收，但很难确定永久代的大小，因为它受到很多因素影响，并且每次 Full GC 之后永久代的大小都会改变，所以经常会抛出OutOfMemoryError异常。为了更容易管理方法区，hotspot从 JDK 1.8 开始，移除永久代，并把方法区移至元空间，它位于本地内存中，而不是虚拟机内存中。原来永久代的数据被分到了堆和元空间中。元空间存储类的元信息，Class对象、静态变量和字符串常量池等放入堆中。元数据并不是类的Class对象，Class对象是加载的最终产品，静态变量位于 Class对象内，而类的方法代码，变量名，方法名，访问权限，返回值等元数据都是在方法区的。

JDK 1.8 同 JDK 1.7 比，最大的差别就是：元数据区取代了永久代。元空间的本质和永久代类似，都是hotspot对 JVM 规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元数据空间并不在虚拟机中，而是使用本地内存。

字符串常量池从永久代划到Java堆：由于字符串常量池具备动态性，在程序运行过程中会有大量的字符串常量在运行时常量池里产生，此时如果放在永久代，则无法恰当的设定永久代的大小，容易出现性能问题和内存溢出。

运行时常量池依旧还是在方法区里

为什么移除永久代？

1. 方法区大小难以设定，容易发生内存溢出。永久代会存放Class的相关信息，一般这些信息在编译期间就能确定大小。但是如果是在一些需要动态生成大量Class的应用中，如：Spring的动态代理、大量的JSP页面或动态生成JSP页面等，由于方法区的大小在一开始就要分配好，因此就能难确定大小，容易出现内存溢出
2. GC复杂且效率低。方法区存储了类的元数据信息和各种常量，它的内存回收目标理应当是对这些类型的卸载和常量的回收。但由于这些数据被类的实例引用，卸载条件变得复杂且严格，回收不当会导致堆中的类实例失去元数据信息和常量信息。因此，回收方法区内存不是一件简单高效的事情。
3. 促进HotSpot JVM与JRockit VM的融合。JRockit没有方法区，移除永久代可以促进HotSpot JVM与JRockit VM的融合。

什么是元空间（Metaspace），为什么引入元空间

元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。

元空间的特点：

1. 每个加载器有专门的存储空间。
2. 不会单独回收某个类。
3. 元空间里的对象的位置是固定的。
4. 如果发现某个加载器不再存活了，会把相关的空间整个回收。

8、何时full gc

只有参考作用，不同收集器实现不同。

1. System.gc() 方法的调用
   此方法的调用是建议 JVM 进行 Full GC，注意这只是建议而非一定，但在很多情况下它会触发 Full GC，从而增加 Full GC 的频率。通常情况下我们只需要让虚拟机自己去管理内存即可，我们可以通过 -XX:+ DisableExplicitGC 来禁止调用 System.gc()。
2. CMS GC 时出现 promotion failed 和 concurrent mode failure
   promotion failed，就是上文所说的担保失败，而 concurrent mode failure 是在执行 CMS GC 的过程中同时有对象要放入老年代，而此时老年代空间不足造成的。
3. 统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间

9、内存分配与回收策略

Java默认新生代老年代比例：1：2

1. 对象优先在 Eden 分配

   大多数情况下，对象在新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

2. 大对象直接进入老年代

   大对象是指需要大量连续内存空间的 Java 对象，如很长的字符串或数据。

   一个大对象能够存入 Eden 区的概率比较小，发生分配担保的概率比较大，而分配担保需要涉及大量的复制，就会造成效率低下。

   虚拟机提供了一个 -XX:PretenureSizeThreshold 参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在 Eden 区及两个 Survivor 区之间发生大量的内存复制。

3. 长期存活的对象将进入老年代

   JVM 给每个对象定义了一个对象年龄计数器。当新生代发生一次 Minor GC 后，存活下来的对象年龄 +1，当年龄超过一定值时，就将超过该值的所有对象转移到老年代中去。

   使用 -XXMaxTenuringThreshold 设置新生代的最大年龄，只要超过该参数的新生代对象都会被转移到老年代中去。

4. 动态对象年龄判定

   如果当前新生代的 Survivor 中，相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。

5. 空间分配担保

   只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行 Minor GC，否则将进行 Full GC。通过清除老年代中废弃数据来扩大老年代空闲空间，以便给新生代作担保。

10、为什么HashMap在链表长度为8时才转红黑树，不直接用红黑树

基于时间和空间的权衡，大部分桶的链表长度在负载因子的影响下都会小于8，极少数才会大于8，而且红黑树操作复杂，不如链表直接头插快。

11、MySQL索引的作用

（1）快速取数据；
（2）保证数据记录的唯一性；
（3）实现表与表之间的参照完整性；
（4）在使用ORDER by、group by子句进行数据检索时，利用索引可以减少排序和分组的时间。

12、为什么ConcurrentHashMap的读操作不需要加锁？

get操作源码：

1. 首先计算hash值，定位到该table索引位置，如果是首节点符合就返回
2. 如果遇到扩容的时候，会调用标志正在扩容节点ForwardingNode的find方法，查找该节点，匹配就返回
3. 以上都不符合的话，就往下遍历节点，匹配就返回，否则最后就返回null

//会发现源码中没有一处加了锁
public V get(Object key) {
    Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek;
    int h = spread(key.hashCode()); //计算hash
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (e = tabAt(tab, (n - 1) & h)) != null) {//读取首节点的Node元素
        if ((eh = e.hash) == h) { //如果该节点就是首节点就返回
            if ((ek = e.key) == key || (ek != null && key.equals(ek)))
                return e.val;
        }
        //hash值为负值表示正在扩容，这个时候查的是ForwardingNode的find方法来定位到nextTable来
        //eh=-1，说明该节点是一个ForwardingNode，正在迁移，此时调用ForwardingNode的find方法去nextTable里找。
        //eh=-2，说明该节点是一个TreeBin，此时调用TreeBin的find方法遍历红黑树，由于红黑树有可能正在旋转变色，所以find里会有读写锁。
        //eh>=0，说明该节点下挂的是一个链表，直接遍历该链表即可。
        else if (eh < 0)
            return (p = e.find(h, key)) != null ? p.val : null;
        while ((e = e.next) != null) {//既不是首节点也不是ForwardingNode，那就往下遍历
            if (e.hash == h &&
                ((ek = e.key) == key || (ek != null && key.equals(ek))))
                return e.val;
        }
    }
    return null;
}

get操作可以无锁是由于Node的元素val和指针next是用volatile修饰的，在多线程环境下线程A修改结点的val或者新增节点的时候是对线程B可见的。

static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    //可以看到这些都用了volatile修饰
    volatile V val;
    volatile Node<K,V> next;
}

13、关于一致性

分布式数据一致性（数据多份副本一致性）

数据的一致性和系统的性能是每个分布式系统都需要考虑和权衡的问题。一致性的级别如下：
1.强一致性
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大
2.弱一致性
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不久承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态
3、最终一致性
最终一致性是弱一致性的一个特例，系统会保证在一定时间内，能够达到一个数据一致的状态。这里之所以将最终一致性单独提出来，是因为它是弱一致性中非常推崇的一种一致性模型，也是业界在大型分布式系统的数据一致性上比较推崇的模型

一致性hash

通过环的方式来分配数据。

cap理论的一致性

Consistency(一致性)

• 通过某个节点的写操作结果对后面通过其他节点的读操作可见
• 如果更新数据后，并发访问情况下可立即感知该更新，称为强一致性
• 如果允许之后部分或者全部感知不到该更新，称为弱一致性
• 若在之后的一段时间（通常该时间不固定）后，一定可以感知该更新，称为最终一致性

Availability（可用性）

• 任何一个没有发生故障的节点必须在有限时间内返回合理的结果

Partition tolerance（分区容忍性）

• 部分节点宕机或者无法与其他节点通信时，各分区还可保持分布式系统的功能。

ACID里的一致性

在ACID的上下文中，一致性是指数据库在应用程序的特定概念中处于“良好状态”。

ACID一致性的概念是，对数据的一组特定约束必须始终成立。即不变量（invariants）。例如，在会计系统中，所有账户整体上必须借贷相抵。如果一个事务开始于一个满足这些不变量的有效数据库，且在事务处理期间的任何写入操作都保持这种有效性，那么可以确定，不变量总是满足的。

但是，一致性的这种概念取决于应用程序对不变量的观念，应用程序负责正确定义它的事务，并保持一致性。这并不是数据库可以保证的事情：如果你写入违反不变量的脏数据，数据库也无法阻止你。 （一些特定类型的不变量可以由数据库检查，例如外键约束或唯一约束，但是一般来说，是应用程序来定义什么样的数据是有效的，什么样是无效的。—— 数据库只管存储。）

原子性，隔离性和持久性是数据库的属性，而一致性（在ACID意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母C不属于ACID[^i]。

[^i]: 乔·海勒斯坦（Joe Hellerstein）指出，在论Härder与Reuter的论文中，“ACID中的C”是被“扔进去凑缩写单词的”【7】，而且那时候大家都不怎么在乎一致性。

14、MySQL如何解决幻读？

SELECT查询分为快照读和实时读，快照读通过MVCC（并发多版本控制）来解决幻读问题，实时读通过行锁来解决幻读问题。

快照读

快照读是什么？

因为MySQL默认的隔离级别是可重复读，这种隔离级别下，我们普通的SELECT语句都是快照读，也就是在一个事务内，多次执行SELECT语句，查询到的数据都是事务开始时那个状态的数据（这样就不会受其他事务修改数据的影响），这样就解决了幻读的问题。

那么innodb是怎么解决快照读的幻读问题的？

快照读就是每一行数据中额外保存两个隐藏的列，插入这个数据行时的版本号，删除这个数据行时的版本号（可能为空），滚动指针(指向undo log中用于事务回滚的日志记录)。

事务在对数据修改后，进行保存时，如果数据行的当前版本号与事务开始取得数据的版本号一致就保存成功，否则保存失败。

当我们不显式使用BEGIN来开启事务时，我们执行的每一条语句就是一个事务，每次开始事务时，会对系统版本号+1作为当前事务的ID。

插入操作

插入一行数据时，将事务的ID作为数据行的创建版本号。

删除操作

执行删除操作时，会将原数据行的删除版本号设置为当前事务的ID，然后根据原数据行生成一条INSERT语句，写入undo log，用于事务执行失败时回滚。delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。但是会将数据行的删除版本号设置为当前的事务的ID，这样后面的事务B即便查到这行数据由于事务B的ID>删除版本号，也会忽略这条数据。

更新操作

更新时可以简单的认为是先将旧数据删除，然后插入一条新数据。

所以执行更新操作时，其实是会将原数据行的删除版本号设置为当前事务的ID，生成一条INSERT语句，写入undo log，用于事务执行失败时回滚。插入一条新的数据，将事务的ID作为数据行的的创建版本号。

查询操作

数据行要被查询出来必须满足两个条件，

• 数据行删除版本号为空或者>当前事务版本号的数据（否则数据已经被标记删除了)
• 创建版本号<=当前事务版本号的数据（否则数据是后面的事务创建出来的）

简单来说，就是查询时，

• 如果该行数据没有被加行锁中的X锁（也就是没有其他事务对这行数据进行修改），那么直接读取数据（前提是数据的版本号<=当前事务版本号的数据,不然不会放到查询结果集里面）。
• 该行数据被加了行锁X锁（也就是现在有其他事务对这行数据进行修改），那么读数据的事务不会进行等待，而是回去undo log端里面读之前版本的数据（这里存储的数据本身是用于回滚的），在可重复读的隔离级别下，从undo log中读取的数据总是事务开始时的快照数据(也就是版本号小于当前事务ID的数据)，在提交读的隔离级别下，从undo log中读取的总是最新的快照数据。

补充资料：undo log段是什么？

undo_log是一种逻辑日志，是旧数据的备份。有两个作用，用于事务回滚和为MVCC提供老版本的数据。

可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。

用于事务回滚

当事务执行失败，回退时，会读取这行数据的滚动指针(指向undo log中用于事务回滚的日志记录)，就可以在undo log中找到相应的逻辑记录，读取到相应的回滚语句，执行进行回滚。

为MVCC提供老版本的数据

当读取的某一行被其他事务锁定时（也就是有其他事务正在改这行数据），它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户进行快照读。在可重复读的隔离级别下，从undo log中读取的数据总是事务开始时的快照数据(也就是版本号小于当前事务ID的数据)，在提交读的隔离级别下，从undo log中读取的总是最新的快照数据（也就是比正在修改这行数据的事务ID修改前的数据。）。

实时读

实时读是什么？

如果说快照读总是读取事务开始时那个状态的数据，实时读就是查询时总是执行这个查询时数据库中的数据。

一般使用以下这两种查询语句进行查询时就是实时读。

SELECT *** FOR UPDATE 在查询时会先申请X锁SELECT *** IN SHARE MODE 在查询时会先申请S锁

那么innodb是怎么解决实时读的幻读问题的？

如果我们不在一开始将将隔离级别设置为提交读，其实是不会产生幻读问题的，因为MySQL的默认隔离级别是可重复读，在这种情况下，我们执行第一次 SELECT…FOR UPDATE查询语句是，其实是会先申请行锁，因为一开始数据库就只有a:4一行数据，那么加锁区间其实是

(负无穷，4](4,正无穷)

我们查询条件是a>2，上面两个加锁区间都会可能有数据满足条件，所以会申请行锁中的next-key lock，是会对上面这两个区间都加锁，这样其他事务不能往这两个区间插入数据，事务B会执行插入时会一直等待获取锁，直到事务A提交，释放行锁，事务B才有可能申请到锁，然后进行插入。这样就解决了幻读问题。

贴一个《设计数据密集型应用》的段落，讲的不错：

与读取提交的隔离类似，快照隔离的实现通常使用写锁来防止脏写，这意味着进行写入的事务会阻止另一个事务修改同一个对象。但是读取不需要任何锁定。从性能的角度来看，快照隔离的一个关键原则是：读不阻塞写，写不阻塞读。这允许数据库在处理一致性快照上的长时间查询时，可以正常地同时处理写入操作。且两者间没有任何锁定争用。

数据库必须可能保留一个对象的几个不同的提交版本，因为各种正在进行的事务可能需要看到数据库在不同的时间点的状态。因为它并排维护着多个版本的对象，所以这种技术被称为多版本并发控制（MVCC, multi-version concurrency control）。

如果一个数据库只需要提供读已提交的隔离级别，而不提供快照隔离，那么保留一个对象的两个版本就足够了：提交的版本和被覆盖但尚未提交的版本。支持快照隔离的存储引擎通常也使用MVCC来实现读已提交隔离级别。一种典型的方法是读已提交为每个查询使用单独的快照，而快照隔离对整个事务使用相同的快照。

图7-7说明了如何在PostgreSQL中实现基于MVCC的快照隔离【31】（其他实现类似）。当一个事务开始时，它被赋予一个唯一的，永远增长[^vii]的事务ID（txid）。每当事务向数据库写入任何内容时，它所写入的数据都会被标记上写入者的事务ID。

[^vii]: 事实上，事务ID是32位整数，所以大约会在40亿次事务之后溢出。 PostgreSQL的Vacuum过程会清理老旧的事务ID，确保事务ID溢出（回卷）不会影响到数据。

图7-7 使用多版本对象实现快照隔离

表中的每一行都有一个 created_by 字段，其中包含将该行插入到表中的的事务ID。此外，每行都有一个 deleted_by 字段，最初是空的。如果某个事务删除了一行，那么该行实际上并未从数据库中删除，而是通过将 deleted_by 字段设置为请求删除的事务的ID来标记为删除。在稍后的时间，当确定没有事务可以再访问已删除的数据时，数据库中的垃圾收集过程会将所有带有删除标记的行移除，并释放其空间。[^译注ii]

[^译注ii]: 在PostgreSQL中，created_by 的实际名称为xmin，deleted_by 的实际名称为xmax

UPDATE 操作在内部翻译为 DELETE 和 INSERT 。例如，在图7-7中，事务13 从账户2 中扣除100美元，将余额从500美元改为400美元。实际上包含两条账户2 的记录：余额为 $500 的行被标记为被事务13删除，余额为 $400 的行由事务13创建。