從一道面試題開始

看到這個標題，你肯定以為我又要講這道面試題了

//  這行代碼創建了幾個對象？
String s3 = new String("1");

是的，沒錯，我確實要從這裏開始

這道題就算你沒做過也肯定看到，總所周知，它創建了兩個對象，一個位於堆上，一個位於常量池中。

這個答案粗看起來是沒有任何問題的，但是仔細思考確經不起推敲。

如果你覺得我說的不對的話，那麼可以思考下面這兩個問題

1. 你說它創建了兩個對象，那麼這兩個對象分別是怎樣創建的呢？我們回顧下Java創建對象的方式，一共就這麼幾種

   • 使用new關鍵字創建對象
   • 使用反射創建對象（包括Class類的newInstance方法，以及Constructor類的newInstance方法）
   • 使用clone複製一個對象
   • 反序列化得到一個對象

   你說它創建了兩個對象，那你告訴我除了new出來那個對象外，另外一個對象怎麼創建出來的？

2. 堆跟常量池到底什麼關係？不是說在JDK1.7之後（含1.7版本）常量池已經移到了堆中了嗎？如果說常量池本身就位於堆中的話，那麼這種一個對象在堆中，一個對象在常量池的說法還準確嗎？

如果你也產生過這些疑問的話，那麼請耐心看完這篇文章！要解釋上面的問題首先我們得對常量池有個準確的認知。

常量池

通常來說，我們提到的常量池分為三種

• class文件中的常量池
• 運行時常量池
• 字符串常量池

對於這三種常量池，我們需要搞懂下面幾個問題？

1. 這個常量池在哪裡？
2. 這個常量池用來干什麼呢？
3. 這三者有什麼關係？

接下來，我們帶着這些問題往下看

class文件中的常量池

位置在哪？

顧名思義，class文件中的常量池當然是位於class文件中，而class文件又是位於磁盤上。

用來干什麼的？

在學習class文件中的常量池前，我們首選需要對class文件的結構有一定了解

Class文件是一組以8個字節為基礎單位的二進制流，各個數據項目嚴格按照順序緊湊地排列在文

件之中，中間沒有添加任何分隔符，這使得整個Class文件中存儲的內容幾乎全部是程序運行的必要數

據，沒有空隙存在。

​ ————《深入理解Java虛擬機》

整個class文件的組成可以用下圖來表示

對本文而言，我們只關注其中的常量池部分，常量池可以理解為class文件中資源倉庫，它是class文件結構中與其它項目關聯最多的數據類型，主要用於存放編譯器生成的各種字面量(Literal)和符號引用(Symbolic References)。
字面量就是我們所說的常量概念，如文本字符串、被聲明為final的常量值等。
符號引用是一組符號來描述所引用的目標，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標即可（它與直接引用區分一下，直接引用一般是指向方法區的本地指針，相對偏移量或是一個能間接定位到目標的句柄）。一般包括下面三類常量：

• 類和接口的全限定名
• 字段的名稱和描述符
• 方法的名稱和描述符

現在我們知道了class文件中常量池的作用：存放編譯器生成的各種字面量(Literal)和符號引用(Symbolic References)。很多時候知道了一個東西的概念並不能說你會了，對於程序員而言，如果你說你已經會了，那麼最好的證明是你能夠通過代碼將其描述出來，所以，接下來，我想以一種直觀的方式讓大家感受到常量池的存在。通過分析一段簡單代碼的字節碼，讓大家能更好感知常量池的作用。

​ talk is cheap ,show me code

我們以下面這段代碼為例，通過javap來查看class文件中的具體內容，代碼如下：

/**
 * @author 程序員DMZ
 * @Date Create in 22:59 2020/6/15
 * @公眾號 微信搜索：程序員DMZ
 */
public class Main {
    public static void main(String[] args) {
        String name = "dmz";
    }
}

進入Main.java文件所在目錄，執行命令：javac Main.java ，那麼此時會在當前目錄下生成對應的Main.class文件。再執行命令：javap -v -c Main.class，此時會得到如下的解析后的字節碼信息

public class com.dmz.jvm.Main
  minor version: 0
  major version: 52
  flags: ACC_PUBLIC, ACC_SUPER
// 這裏就是常量池了
Constant pool:
   #1 = Methodref          #4.#20         // java/lang/Object."<init>":()V
   #2 = String             #21            // dmz
   #3 = Class              #22            // com/dmz/jvm/Main
   #4 = Class              #23            // java/lang/Object
   #5 = Utf8               <init>
   #6 = Utf8               ()V
   #7 = Utf8               Code
   #8 = Utf8               LineNumberTable
   #9 = Utf8               LocalVariableTable
  #10 = Utf8               this
  #11 = Utf8               Lcom/dmz/jvm/Main;
  #12 = Utf8               main
  #13 = Utf8               ([Ljava/lang/String;)V
  #14 = Utf8               args
  #15 = Utf8               [Ljava/lang/String;
  #16 = Utf8               name
  #17 = Utf8               Ljava/lang/String;
  #18 = Utf8               SourceFile
  #19 = Utf8               Main.java
  #20 = NameAndType        #5:#6          // "<init>":()V
  #21 = Utf8               dmz
  #22 = Utf8               com/dmz/jvm/Main
  #23 = Utf8               java/lang/Object
 // 下面是方法表                           
{
  public com.dmz.jvm.Main();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 7: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Lcom/dmz/jvm/Main;

  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=1, locals=2, args_size=1
         // 可以看到方法表中的指令引用了常量池中的常量，這也是為什麼說常量池是資源倉庫的原因
         // 因為它會被class文件中的其它結構引用         
         0: ldc           #2                  // String dmz
         2: astore_1
         3: return
      LineNumberTable:
        line 9: 0
        line 10: 3
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       4     0  args   [Ljava/lang/String;
            3       1     1  name   Ljava/lang/String;
}
SourceFile: "Main.java"

在上面的字節碼中，我們暫且關注常量池中的內容即可。主要看這兩行

#2 = String             #14            // dmz
#14 = Utf8               dmz

如果要看懂這兩行代碼，我們需要對常量池中String類型常量的結構有一定了解，其結構如下：

對應到我們上面的字節碼中，tag=String，index=#14，所以我們可以知道，#2是一個字面量為#14的字符串類型常量。而#14對應的字面量信息（一個Utf8類型的常量）就是dmz。

常量池作為資源倉庫，最大的用處在於被class文件中的其它結構所引用，這個時候我們再將注意力放到main方法上來，對應的就是這三條指令

0: ldc           #2                  // String dmz
2: astore_1
3: return

ldc：這個指令的作用是將對應的常量的引用壓入操作數棧，在執行ldc指令時會觸發對它的符號引用進行解析，在上面例子中對應的符號引用就是#2，也就是常量池中的第二個元素（這裏就能看出方法表中就引用了常量池中的資源）

astore_1：將操作數棧底元素彈出，存儲到局部變量表中的1號元素

return：方法返回值為void，標誌方法執行完成，將方法對應棧幀從棧中彈出

下面我用畫圖的方式來畫出整個流程，主要分為四步

1. 解析ldc指令的符號引用（#2）

2. 將#2對應的常量的引用壓入到操作數棧頂

3. 將操作數棧的元素彈出並存儲到局部變量表中

4. 執行return指令，方法執行結束，彈出棧區該方法對應的棧幀

第一步：

在解析#2這個符號引用時，會先到字符串常量池中查找是否存在對應字符串實例的引用，如果有的話，那麼直接返回這個字符串實例的引用，如果沒有的話，會創建一個字符串實例，那麼將其添加到字符串常量池中（實際上是將其引用放入到一個哈希表中），之後再返回這個字符串實例對象的引用。

到這裏也能回答我們之前提出的那個問題了，一個對象是new出來的，另外一個是在解析常量池的時候JVM自動創建的

第二步：

將第一步得到的引用壓入到操作數棧，此時這個字符串實例同時被操作數棧以及字符串常量池引用。

第三步：

操作數棧中的引用彈出，並賦值給局部變量表中的1號位置元素，到這一步其實執行完了String name = "dmz"這行代碼。此時局部變量表中儲存着一個指向堆中字符串實例的引用，並且這個字符串實例同時也被字符串常量池引用。

第四步：

這一步我就不畫圖了，就是方法執行完成，棧幀彈出，非常簡單。

在上文中，我多次提到了字符串常量池，它到底是個什麼東西呢？我們還是分為兩部分討論

1. 位置在哪?
2. 用來干什麼的？

字符串常量池

位置在哪？

字符串常量池比較特殊，在JDK1.7之前，其存在於永久代中，到JDK1.7及之後，已經中永久代移到了堆中。當然，如果你非要說永久代也是堆的一部分那我也沒辦法。

另外還要說明一點，經常有同學會將方法區，元空間，永久代（permgen space）的概念混淆。請注意

1. 方法區是JVM在內存分配時需要遵守的規範，是一個理論，具體的實現可以因人而異
2. 永久代是hotspot 的jdk1.8以前對方法區的實現，使用jdk1.7的老司機肯定以前經常遇到過java.lang.OutOfMemoryError: PremGen space異常。這裏的PermGen space其實指的就是方法區。不過方法區和PermGen space又有着本質的區別。前者是JVM的規範，而後者則是JVM規範的一種實現，並且只有HotSpot才有PermGen space。
3. 元空間是jdk1.8對方法區的實現，jdk1.8徹底移除了永久代，其實，移除永久代的工作從JDK 1.7就開始了。JDK 1.7中，存儲在永久代的部分數據就已經轉移到Java Heap或者Native Heap。但永久代仍存在於JDK 1.7中，並沒有完全移除，譬如符號引用(Symbols)轉移到了native heap；字面量(interned strings)轉移到了Java heap；類的靜態變量(class statics)轉移到了Java heap。到jdk1.8徹底移除了永久代，將JDK7中還剩餘的永久代信息全部移到元空間，元空間相比對永久代最大的差別是，元空間使用的是本地內存（Native Memory）。

用來干什麼的？

字符串常量池，顧名思義，肯定就是用來存儲字符串的嘛，準確來說存儲的是字符串實例對象的引用。我查閱了很多博客、資料，它們都會說，字符串常量池中存儲的就是字符串對象。其實我們可以類比下面這段代碼：

HashSet<Person> persons = new HashSet<Person>;

在persons這個集合中，存儲的是Person對象還是Person對象對應的引用呢？

所以，請大聲跟我念三遍

字符串常量池存儲的是字符串實例對象的引用！

字符串常量池存儲的是字符串實例對象的引用！

字符串常量池存儲的是字符串實例對象的引用！

下面我們來看R大博文下評論的一段話：

簡單來說，HotSpot VM里StringTable是個哈希表，裏面存的是駐留字符串的引用（而不是駐留字符串實例自身）。也就是說某些普通的字符串實例被這個StringTable引用之後就等同被賦予了“駐留字符串”的身份。這個StringTable在每個HotSpot VM的實例里只有一份，被所有的類共享。類的運行時常量池裡的CONSTANT_String類型的常量，經過解析（resolve）之後，同樣存的是字符串的引用；解析的過程會去查詢StringTable，以保證運行時常量池所引用的字符串與StringTable所引用的是一致的。

​ ——R大博客

從上面我們可以知道

1. 字符串常量池本質就是一個哈希表
2. 字符串常量池中存儲的是字符串實例的引用
3. 字符串常量池在被整個JVM共享
4. 在解析運行時常量池中的符號引用時，會去查詢字符串常量池，確保運行時常量池中解析后的直接引用跟字符串常量池中的引用是一致的

為了更好理解上面的內容，我們需要去分析String中的一個方法—–intern()

intern方法分析

/** 
 * Returns a canonical representation for the string object. 
 * <p> 
 * A pool of strings, initially empty, is maintained privately by the 
 * class <code>String</code>. 
 * <p> 
 * When the intern method is invoked, if the pool already contains a 
 * string equal to this <code>String</code> object as determined by 
 * the {@link #equals(Object)} method, then the string from the pool is 
 * returned. Otherwise, this <code>String</code> object is added to the 
 * pool and a reference to this <code>String</code> object is returned. 
 * <p> 
 * It follows that for any two strings <code>s</code> and <code>t</code>, 
 * <code>s.intern()&nbsp;==&nbsp;t.intern()</code> is <code>true</code> 
 * if and only if <code>s.equals(t)</code> is <code>true</code>. 
 * <p> 
 * All literal strings and string-valued constant expressions are 
 * interned. String literals are defined in section 3.10.5 of the 
 * <cite>The Java&trade; Language Specification</cite>. 
 * 
 * @return  a string that has the same contents as this string, but is 
 *          guaranteed to be from a pool of unique strings. 
 */  
public native String intern();  

String#intern方法中看到，這個方法是一個 native 的方法，但註釋寫的非常明了。“如果常量池中存在當前字符串, 就會直接返回當前字符串. 如果常量池中沒有此字符串, 會將此字符串放入常量池中后, 再返回”。

關於其詳細的分析可以參考：美團：深入解析String#intern

珠玉在前，所以本文着重就分析下intern方法在JDK不同版本下的差異，首先我們要知道引起差異的原因是因為JDK1.7及之後將字符串常量池從永久代挪到了堆中。

我這裏就以美團文章中的示例代碼來進行分析，代碼如下：

public static void main(String[] args) {
    String s = new String("1");
    s.intern();
    String s2 = "1";
    System.out.println(s == s2);

    String s3 = new String("1") + new String("1");
    s3.intern();
    String s4 = "11";
    System.out.println(s3 == s4);
}

打印結果是

• jdk6 下false false
• jdk7 下false true

在美團的文章中已經對這個結果做了詳細的解釋，接下來我就用我的圖解方式再分析一波這個過程

jdk6 執行流程

第一步：執行 String s = new String("1")，要清楚這行代碼的執行過程，我們還是得從字節碼入手，這行代碼對應的字節碼如下：

  public static void main(java.lang.String[]);
    Code:
       0: new           #2                  // class java/lang/String
       3: dup
       4: ldc           #3                  // String 1
       6: invokespecial #4                  // Method java/lang/String."<init>":(Ljava/lang/String;)V
       9: astore_1
      10: return

new ：創建了一個類的實例（還沒有調用構造器函數），並將其引用壓入操作數棧頂

dup：複製棧頂數值並將複製值壓入棧頂，這是因為invokespecial跟astore_1各需要消耗一個引用

ldc：解析常量池符號引用，將實際的直接引用壓入操作數棧頂

invokespecial：彈出此時棧頂的常量引用及對象引用，執行invokespecial指令，調用構造函數

astore_1：將此時操作數棧頂的元素彈出，賦值給局部變量表中1號元素（0號元素存的是main函數的參數）

我們可以將上面整個過程分為兩個階段

1. 解析常量
2. 調用構造函數創建對象並返回引用

在解析常量的過程中，因為該字符串常量是第一次解析，所以會先在永久代中創建一個字符串實例對象，並將其引用添加到字符串常量池中。此時內存狀態如下：

當真正通過new方式創建對象完成后，對應的內存狀態如下，因為在分析class文件中的常量池的時候已經對棧區做了詳細的分析，所以這裏就省略一些細節了，在執行完這行代碼后，棧區存在一個引用，指向 了堆區的一個字符串實例內存狀態對應如下：

第二步：緊接着，我們調用了s的intern方法，對應代碼就是 s.intern()

當intern方法執行時，因為此時字符串常量池中已經存在了一個字面量信息跟s相同的字符串的引用，所以此時內存狀態不會發生任何改變。

第三步：執行String s2 = "1",此時因為常量池中已經存在了字面量1的對應字符串實例的引用，所以，這裏就直接返回了這個引用並且賦值給了局部變量s2。對應的內存狀態如下：

到這裏就很清晰了，s跟s2指向兩個不同的對象，所以s==s2肯定是false嘛~

如果看過美團那篇文章的同學可能會有些疑惑，我在圖中對常量池的描述跟美團文章圖中略有差異，在美團那篇文章中，直接將具體的字符串實例放到了字符串常量池中，而在我上面的圖中，字符串常量池存的永遠時引用，它的圖是這樣畫的

就我查閱的資料而言，我個人不贊同這種說法，常量池中應該保存的僅僅是引用。關於這個問題，我已經向美團的團隊進行了留言，也請大佬出來糾錯！

接着我們分析s3跟s4，對應的就是這幾行代碼：

String s3 = new String("1") + new String("1");
s3.intern();
String s4 = "11";
System.out.println(s3 == s4);

我們一行行分析，看看執行完后，內存的狀態是什麼樣的

第一步：String s3 = new String("1") + new String("1")，執行完成后，堆區多了兩個匿名對象，這個我們不用多關注，另外堆區還多了一個字面量為11的字符串實例，並且棧中存在一個引用指向這個實例

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-NVeeWKoO-1592334452491)(upload\image-20200617020742618.png)]

實際上上圖中還少了一個匿名的StringBuilder的對象，這是因為當我們在進行字符串拼接時，編譯器默認會創建一個StringBuilder對象並調用其append方法來進行拼接，最後再調用其toString方法來轉換成一個字符串，StringBuilder的toString方法其實就是new一個字符串

public String toString() {
    // Create a copy, don't share the array
    return new String(value, 0, count);
}

這也是為什麼在圖中會說在堆上多了一個字面量為11的字符串實例的原因，因為實際上就是new出來的嘛！

第二步：s3.intern()

調用intern方法后，因為字符串常量池中目前沒有11這個字面量對應的字符串實例的應用，所以JVM會先從堆區複製一個字符串實例到永久代中，再將其引用添加到字符串常量池中，最終的內存狀態就如下所示

第三步：String s4 = "11"

這應該沒啥好說的了吧，常量池中有了，直接指向對應的字符串實例

到這裏可以發現，s3跟s4指向的根本就是兩個不同的對象，所以也返回false

jdk7 執行流程

在jdk1.7中，s跟s2的執行結果還是一樣的，這是因為 String s = new String("1")這行代碼本身就創建了兩個字符串對象，一個屬於被常量池引用的駐留字符串，而另外一個只是堆上的一個普通字符串對象。跟1.6的區別在於，1.7中的駐留字符串位於堆上，而1.6中的位於方法區中，但是本質上它們還是兩個不同的對象，在下面代碼執行完后

    String s = new String("1");
    s.intern();
    String s2 = "1";
    System.out.println(s == s2);

內存狀態為：

但是對於s3跟s4確不同了，因為在jdk1.7中不會再去複製字符串實例了，在intern方法執行時在發現堆上有對應的對象之後，直接將這個對應的引用添加到字符串常量池中，所以代碼執行完，內存狀態對應如下：

看到了吧，s3跟s4指向的同一個對象，這是因為intern方法執行時，直接s3這個引用複製到了常量池，之後執行String s4= "11"的時候，直接再將常量池中的引用複製給了s4，所以s3==s4肯定為true啦。

在理解了它們之間的差異之後，我們再來思考一個問題，假設我現在將代碼改成這個樣子，那麼運行結果是什麼樣的呢？

public static void main(String[] args) {
    String s = new String("1");
    String sintern = s.intern();
    String s2 = "1";
    System.out.println(sintern == s2);

    String s3 = new String("1") + new String("1");
    String s3intern = s3.intern();
    String s4 = "11";
    System.out.println(s3intern == s4);
}

上面這段代碼運行起來結果會有差異嗎？大家可以自行思考~

在我們對字符串常量池有了一定理解之後會發現，其實通過String name = "dmz"這行代碼申明一個字符串，實際的執行邏輯就像下面這段偽代碼所示

/**
  * 這段代碼邏輯類比於
  * <code>String s = "字面量"</code>;這種方式申明一個字符串
  * 其中字面量就是在""中的值
  *
  */
public String declareString(字面量) {
    String s;
    // 這是一個偽方法，標明會根據字面量的值到字符串值中查找是否存在對應String實例的引用
    s = findInStringTable(字面量);
    // 說明字符串池中已經存在了這個引用，那麼直接返回
    if (s != null) {
        return s;
    }
    // 不存在這個引用，需要新建一個字符串實例，然後調用其intern方法將其拘留到字符串池中，
    // 最後返回這個新建字符串的引用
    s = new String(字面量);
    // 調用intern方法，將創建好的字符串放入到StringTable中,
    // 類似就是調用StringTable.add(s)這也的一個偽方法
    s.intern();
    return s;
}

按照這個邏輯，我們將我們將上面思考題中的所有字面量進行替換，會發現不管在哪個版本中結果都應該返回true。

運行時常量池

位置在哪？

位於方法區中，1.6在永久代，1.7在元空間中，永久代跟元空間都是對方法區的實現

用來干什麼？

jvm在執行某個類的時候，必須經過加載、連接、初始化，而連接又包括驗證# 位置在哪？

位於方法區中，1.6在永久代，1.7在元空間中，永久代跟元空間都是對方法區的實現

用來干什麼？

jvm在執行某個類的時候，必須經過加載、連接、初始化，而連接又包括驗證、準備、解析三個階段。而當類加載到內存中后，jvm就會將class常量池中的內容存放到運行時常量池中，由此可知，運行時常量池也是每個類都有一個。在上面我也說了，class常量池中存的是字面量和符號引用，也就是說他們存的並不是對象的實例，而是對象的符號引用值。而經過解析（resolve）之後，也就是把符號引用替換為直接引用，解析的過程會去查詢全局字符串池，也就是我們上面所說的StringTable，以保證運行時常量池所引用的字符串與全局字符串池中所引用的是一致的。

所以簡單來說，運行時常量池就是用來存放class常量池中的內容的。

總結

我們將三者進行一個比較

以一道測試題結束

// 環境1.7及以上
public class Clazz {
    public static void main(String[] args) {
        String s1 = new StringBuilder().append("ja").append("va1").toString();
        String s2 = s1.intern();
        System.out.println(s1==s2);
        
        String s5 = "dmz";
        String s3 = new StringBuilder().append("d").append("mz").toString();
        String s4 = s3.intern();
        System.out.println(s3 == s4);

        String s7 = new StringBuilder().append("s").append("pring").toString();
        String s8 = s7.intern();
        String s6 = "spring";
        System.out.println(s7 == s8);
    }
}

答案是true,false,true。大家可以仔細思考為什麼，如有疑惑可以給我留言，或者進群交流！

如果本文對你有幫助的話，記得點個贊吧！也歡迎關注我的公眾號，微信搜索：程序員DMZ，或者掃描下方二維碼，跟着我一起認認真真學Java,踏踏實實做一個coder。

我叫DMZ，一個在學習路上匍匐前行的小菜鳥！

參考文章：

R大博文：請別再拿“String s = new String(“xyz”);創建了多少個String實例”來面試了吧

R大知乎回答：JVM 常量池中存儲的是對象還是引用呢？

Java中幾種常量池的區分

方法區，永久代和元空間

美團：深入解析String#intern

參考書籍：

《深入理解Java虛擬機》第二版

《深入理解Java虛擬機》第三版

《Java虛擬機規範》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

閱讀本文大概需要 11 分鐘。

原文：https://bit.ly/2UMiDLb
作者：Jon P Smith
翻譯：王亮
聲明：我翻譯技術文章不是逐句翻譯的，而是根據我自己的理解來表述的。其中可能會去除一些本人實在不知道如何組織但又不影響理解的句子。

本文將為你詳細描繪 EF Core 從數據庫中讀取數據的“幕後”視圖。我將揭開兩種數據庫讀取方式的面紗：一個是普通的查詢，另一個是使用 AsNoTracking 方法的非跟蹤查詢。我還將通過一個實驗來演示我是如何解決我的一個客戶遇到的性能問題。

我假設你對 EF Core 已經有了一定的認識，但在深入學習之前，我們先來了解一下如何使用 EF Core，以確保我們已經掌握了一些基本知識。這是一個“深入研究”的課題，所以我準備大量的技術細節，希望我的描述方式你能理解。

本文是“深入理解 EF Core”系列中的第一篇。以下是本系列文章列表：

• 當 EF Core 從數據庫讀取數據時發生了什麼？（本文）
• 當 EF Core 寫入數據到數據庫時發生了什麼？（敬請期待）

概要

• EF Core 有兩種方法從數據庫中讀取數據（也稱為查詢）：普通 LINQ 查詢和包含 AsNoTracking 方法的非跟蹤 LINQ 查詢。
• 這兩種方法查詢的返回類（被稱為實體類），它連接的其它的實體類（即所謂的導航屬性）也被同時加載，但這兩種法如何連接及連接的內容是不一樣的。
• 普通查詢接受的是 DbContext 執行讀取時所有數據的副本——此時的實體類稱為被跟蹤。這允許加載的實體類參与數據庫的更新操作。
• 普通查詢還會有一些其它的複雜底層實現，稱為關係修補(fixup)，用於描述讀入的實體類和其他被跟蹤實體之間的連接關係。
• AsNoTracked 非跟蹤查詢沒有副本，所以它沒有被跟蹤——這意味着它比普通查詢更快。這也意味着它不會用於數據庫的寫操作。
• 最後，我將展示 EF Core 普通查詢中一個鮮為人知的特性，以此作為示例，說明通過導航屬性連接實體類的關係是多麼智能。

EF Core 如何讀取數據庫數據

提示：如果你已經對 EF Core 有一定的認識，那麼你可以跳過這一節，這部分只是一個如何讀取數據庫的例子。

為了能讓你更好地理解，我先描述一個數據庫結構，然後再給出一個簡單的數據庫讀取示例。下面是一些基本表的結構和它們之間的關係。

這些表被映射到具有類似名稱的類，例如 Book、BookAuthor、Author，這些類的屬性名稱與表的字段名稱相同。由於篇幅有限，我不打算展開來講這些類，但您可以在我的 GitHub 倉庫^[1]中查看這些類。

EF Core 讀取數據庫需要下面五部分：

1. 數據庫服務器，如 SQL server, Sqlite, PostgreSQL 等。
2. 具有數據的數據庫。
3. 映射到數據表的類（稱為實體類）。
4. 一個繼承 DbContext 的類，該類包含 EF Core 的配置。
5. 最後，從數據庫讀取數據的命令。

下面的單元測試代碼來自我的 GitHub 創庫^[2]，展示了一個簡單的示例，它從現有數據庫中讀取 4 個 Book 實體及其關聯的 BookAuthor 和 Authors 實體。

倉庫地址：https://bit.ly/2Yza7QQ

[Fact]
public void TestBookCountAuthorsOk()
{
    //SETUP
    var options = SqliteInMemory.CreateOptions<EfCoreContext>();
    //code to set up the database with four books, two with the same Author
    using (var context = new EfCoreContext(options))
    {
        //ATTEMPT
        var books = context.Books
            .Include(r => r.AuthorsLink)
            .ThenInclude(r => r.Author)
            .ToList();

        //VERIFY
        books.Count.ShouldEqual(4);
        books.SelectMany(x => x.AuthorsLink.Select(y => y.Author))
            .Distinct().Count().ShouldEqual(3);
    }
}

現在，如果我們將單元測試代碼對應到上面的 5 部分，結果是這樣的：

1. 數據庫服務器——第 5 行：我選擇了一個 Sqlite 數據庫服務器，在本例中是 SqliteInMemory.CreateOptions 方法，它使用我的一個 NuGet 包 EfCore.TestSupport 創建了一個內存數據庫（內存中的數據庫對於單元測試非常有用，因為你可以為這個測試建立一個新的空數據庫）。
2. 具有數據的數據庫——第 6 行：我將在下一篇文章介紹數據是如何寫入數據庫的，現在假設有一個數據庫包含 4 本書信息，其中兩本書的作者是同一個人。
3. 實體類——代碼里這裏沒有展示，但是你可以在這裏查看這些類^[1]。其中有一個 Books 實體類，通過一個名為 BookAuhor 的實體類多對多關聯 Authors 實體類。
4. 一個繼承 DbContext 的類——第 7 行：EfCoreContext 類繼承了 DbContext 類並配置了從類到數據庫的映射關係（你可以在我的 GitHub 倉庫^[3] 中查看該類）。
5. 從數據庫讀取數據的命令——第 10 到 13 行，這是一個查詢：
   • 第 10 行 — context 為 EfCoreContext 的實例，通過它訪問你的數據庫，.Books 表示您希望訪問 Books 表。
   • 第 11 行 — Include 被稱為貪婪加載，它告訴 EF Core 當它加載 Books 時，也應該加載關聯到的所有 BookAuthor 實體類。
   • 第 12 行 — ThenInclude 是繼續貪婪加載，它告訴 EF Core 當它加載一個 BookAuthor 時，它也應該加載關聯到該 BookAuthor 的 Author 實體類。

所有這一切查詢出來是一個結果集，其中有普通屬性，像 Books 的 Title 屬性；有關聯實體類的導航屬性，像 Books 的 AuthorsLink 屬性。

這個示例稱為查詢或讀取，也是四種數據庫訪問類型之一，即 CRUD(新增、讀取、更新和刪除)。我將在下一篇文章中介紹新增和更新。

EF Core 如何表示讀取的數據

當你查詢數據庫時，EF Core 會將數據庫返回的數據轉換為實體類並填充導航屬性的值。在本節中，我們將研究兩種類型的查詢步驟——普通查詢(即沒有 AsNoTracking 方法，也稱為讀寫查詢)和添加了 AsNoTracking 方法的非跟蹤查詢(稱為只讀查詢)。

我們先來看一下最初 LINQ 語句是如何轉換成數據庫相應的查詢命令然後返回數據的。對於我們將要看到的兩種類型的查詢來說，這是很常見的操作。關於查詢的第一部分，請參見下圖。

有一些非常複雜的代碼將你的 LINQ 轉換為數據庫查詢命令，但這些內部細節我們不必關心。如果你的 LINQ 不能被翻譯，你會從 EF Core 得到一個異常消息，其中包含類似“不能被翻譯”的描述詞語。此外，當數據返回時，像 Value Converters^[4] 這樣的特性可能會調整數據。

本節展示了查詢的第一部分，其中 LINQ 被轉換為數據庫命令並返回所有正確的值。現在我們來看查詢的第二部分，在這裏 EF Core 獲取返回值並將它們轉換為實體類的實例，並填充導航屬性。我們將分別看看兩種類型的查詢。

1. 普通查詢(讀寫查詢)

普通查詢讀取數據的方式可以修改數據並更新到數據庫，這就是我將其稱為讀寫查詢的原因。它不會自動更新數據(請參閱下一篇文章，了解如何寫入數據庫)。如果你要更新數據，你的查詢必須是讀寫查詢。

我在介紹中給出的示例執行的是一個普通讀寫查詢，讀取帶有 AuthorsLink 實例的示例。下面是該示例的查詢部分的代碼：

var books = context.Books
    .Include(r => r.AuthorsLink)
    .ThenInclude(r => r.Author)
    .ToList();

然後 EF Core 通過三個步驟將這些值轉換並填充含有導航屬性的實體類。下圖显示了這三個步驟以及生成的實體類及其導航屬性的實體類。

讓我們來分析一下這三個步驟：

1. 創建類並填充數據。它接受數據庫返回的值，並填充非導航(稱為標量)屬性、字段等。在 Book 實體類中，是 BookId(主鍵)、Title 等屬性——參見上圖左下角淺藍色矩形。
2. 修補關聯關係。首先是填入主鍵和外鍵的信息，它們定義如何相互關聯數據。然後，EF Core 使用這些鍵設置實體類之間的導航屬性(如圖中藍色粗線所示)。這個關係的修補所需的信息不僅是查詢讀入的實體類，它還會查看 DbContext 中跟蹤的每個實體，並填充導航屬性。這是一個強大的功能，但你的被跟蹤實體越多，所需消耗時間也越多——這就是為什麼需要 AsNoTracking 來實現更快的查詢。
3. 創建跟蹤快照。跟蹤快照是返回給用戶的實體類的一個副本，加上它所隱藏的與每個實體類的關聯關係——若一個實體處於被跟蹤狀態，這意味着它將會發生修改並會寫入到數據庫中。

2. 非跟蹤查詢(只讀查詢)

非跟蹤查詢，即使用 AsNoTracking 方法的查詢，是一個只讀查詢。這意味着，當 SaveChanges 方法被調用時，你讀取的任何內容都不會被寫入數據庫。非跟蹤查詢的查詢效率更高，在下一節中，我將介紹非跟蹤查詢以及與普通查詢的其他區別。

在前文的示例之後，我修改了查詢代碼，添加了下面的 AsNoTracking 方法(請看第 2 行)：

var books = context.Books
    .AsNoTracking()
    .Include(r => r.AuthorsLink)
    .ThenInclude(r => r.Author)
    .ToList();

這裏的 LINQ 查詢只有上面的普通查詢的前兩個步驟（沒有第三個步驟）。下圖显示了 AsNoTracking 查詢的步驟。

步驟如下：

1. 創建類並填充數據。它接受數據庫返回的值，並填充非導航(稱為標量)屬性、字段等。在 Book 實體類中，是 BookId(主鍵)、Title 等屬性——參見上圖左下角淺藍色矩形。
2. 修補關聯關係。首先是填入主鍵和外鍵的信息，它們定義如何相互關聯數據。然後，EF Core 使用這些鍵設置實體類之間的導航屬性(如圖中藍色粗線所示)。這個關係的修補所需的信息不僅是查詢讀入的實體類，它還會查看 DbContext 中跟蹤的每個實體，並填充導航屬性。這是一個強大的功能，但你的被跟蹤實體越多，所需消耗時間也越多——這就是為什麼需要 AsNoTracking 來實現更快的查詢。

普通查詢和非跟蹤查詢的區別

現在讓我們比較這兩種查詢比較明顯的區別。

1. 非跟蹤查詢查詢的性能更好。使用非跟蹤查詢查詢的主要原因是性能。非跟蹤查詢查詢表現為：

   • 稍微快一點，使用的內存稍微少一點，因為它不需要創建跟蹤快照。
   • 避免沒有必要的跟蹤快照可以提高 SaveChanges 的性能，因為它不必檢查跟蹤快照以查找更改。
   • 稍微快一點，因為修補關聯關係時沒有所謂的身份解析。這就是為什麼你會得到兩個具有相同數據的 Author 實例。

2. 非跟蹤查詢修補關聯關係時只鏈接查詢中的實體。在普通查詢中，我已經說過修補關聯關係時連接的是查詢中的實體和當前跟蹤的實體，但是非跟蹤查詢只修補查詢中的實體關係。

3. 非跟蹤查詢並不總是代表數據庫關係。這兩種類型查詢之間的關係修補的另一個區別是，非跟蹤查詢關係修補更快，它不需要標識的解析。這可以為數據庫中的同一行生成多個實例——見上圖右下角藍色的 Author 實體和註釋。如果只是向用戶显示數據，那麼這種差異並不重要，但是如果具有業務邏輯，那麼多個實例不能正確反映數據的結構，就可能會有問題。

對層級數據有用的關係修補特性

關聯關係修補的步驟是非常智能的，特別是在普通查詢中。下面我想向你展示我是如何利用關係修補的特性來解決一個客戶項目中的性能問題的。

我曾在一家公司工作，那裡的許多數據處理都是層次化結構的，即數據具有一系列深度不確定的關聯關係。問題是我必須先解析整個層次結構，然後才能呈現這些數據。我最初是通過貪婪的方式加載前兩個層級，然後顯式地加載更深的層級來實現這一點的。它可以工作，但是性能非常慢，並且數據庫因大量單數據庫訪問而超載。

這不得不讓我思考解決辦法，如果普通查詢的關係修補那麼智能的話，它能幫助我提高查詢的性能嗎？它可以！讓我給你舉一個公司員工的例子。下圖显示了我們想要加載的公司的層次結構。

你可以接龍式地使用 .Include(x => x.WorksForMe).ThenInclude(x => x.WorksForMe)… 等等來加載所需的層級信息，但結果是一個 .Include(x => x.WorksForMe) 就夠了。因為 EF Core 的關係修補為你做了剩下的事情，這一點很驚奇，但也很有用。

例如，如果我想查詢角色為 Development 的所有員工(每個員工都有一個名為 WhatTheyDo 的屬性和名為 Role 的屬性，該 Role 包含他們工作的部門)，我可以這樣編寫代碼：

var devDept = context.Employees
    .Include(x => x.WorksFromMe)
    .Where(x => x.WhatTheyDo.HasFlag(Roles.Development))
    .ToList();

這將創建一個查詢，用於加載角色為 Development 的所有員工，並且在員工實體類上修補與 WorksFoMe 導航屬性(集合)和 Manager 導航屬性(單個)的關係。通過只執行一個查詢，既提高了查詢花費的時間，又減少了數據庫服務器上的負載。

總結

你已經看到了兩種類型的查詢，我稱之為 a)普通的讀寫查詢，和 b) 非跟蹤的只讀查詢。對於每一種查詢類型，我都向你展示了 EF Core “幕後”是如何讀取數據並展示的。他們工作方式的不同也表現出他們的優勢和劣勢。

非跟蹤查詢是只讀查詢的解決方案，因為它比普通讀寫查詢更快。但是您應該記住關係修補的機制，它可以在數據庫只有一個關係的情況下創建類的多個實例。

普通的讀寫查詢是查詢跟蹤實體的解決方案，這意味着你可以在創建、更新和刪除數據時使用它們。普通的讀寫查詢確實會佔用更多的時間和內存資源，但是有一些有用的特性，比如自動鏈接到其他被跟蹤的實體類實例。

我希望這篇文章對您有用。祝你編程快樂！

[1]. https://bit.ly/2MXK3ZY
[2]. https://bit.ly/2Yza7QQ
[3]. https://bit.ly/2Y0UORO
[4]. https://bit.ly/2YEyg8j

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※為什麼 USB CONNECTOR 是電子產業重要的元件?

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心