你看，我們通過觀測實驗結(jié)果，又有了新的發(fā)現(xiàn)，同時有了新的問題。

于是我們繼續(xù)迭代。

實驗二

在實驗一的基礎(chǔ)上，我們可以定義一個靜態(tài)變量 V，打印一下它的地址（DATA 段），以及打印一下 main() 函數(shù)的地址（TEXT 段）來比較：

static V: i32 = 0; 
println!("V: {:p}, main(): {:p}", &V, main as *const ()); 

打印結(jié)果（注意每次編譯后運行地址都會不同）：

addr1: 0x7fff2dd3e7f8, vtable1: 0x557a21b9e488 
addr2: 0x7fff2dd3e810, vtable2: 0x557a21b9e488 
V: 0x557a21b910ec, main(): 0x557a21b63e40 

Bingo！實驗二證明了我們的猜測沒錯， 虛表是編譯時就生成好，塞入二進制文件中的 。當(dāng)生成 trait object 時，根據(jù)是哪個類型，再指向?qū)?yīng)的位置。

那么，Rust 為每個類型（比如 String ）編譯時只生成一個 vtable，對么？

我們目前很接近真相，但還有未解的疑問。從目前的實驗中，我們還無法得出這個結(jié)論。實驗一里，我們只用了 Debug trait，這個樣本太小，不具備普遍性。如果對同一個數(shù)據(jù)類型（比如 String）使用不同的 trait，會導(dǎo)致不同的結(jié)果么？我們并不知道。如果結(jié)果相同，那么我們就大概率可以確定，一個類型一張?zhí)摫恚駝t，就應(yīng)該是每個類型的每個 trait 實現(xiàn)，都有一張?zhí)摫怼?/p>

實驗三

于是在實驗三里，我們用同一個類型的兩個不同的 Trait，來生成不同的 trait object，看看其虛表是否是同一個地址：

use std::fmt::{Debug, Display}; 
use std::mem::transmute; 
 
 
fn main() { 
    let s1 = String::from("hello world!"); 
    let s2 = String::from("goodbye world!"); 
    // Display / Debug trait object for s 
    let w1: &dyn Display = &s1; 
    let w2: &dyn Debug = &s1; 
 
 
    // Display / Debug trait object for s1 
    let w3: &dyn Display = &s2; 
    let w4: &dyn Debug = &s2; 
 
 
    // 強行把 triat object 轉(zhuǎn)換成兩個地址 (usize, usize) 
    // 這是不安全的，所以是 unsafe 
    let (addr1, vtable1) = unsafe { transmute::<_, (usize, usize)>(w1 as *const dyn Display) }; 
    let (addr2, vtable2) = unsafe { transmute::<_, (usize, usize)>(w2 as *const dyn Debug) }; 
    let (addr3, vtable3) = unsafe { transmute::<_, (usize, usize)>(w3 as *const dyn Display) }; 
    let (addr4, vtable4) = unsafe { transmute::<_, (usize, usize)>(w4 as *const dyn Debug) }; 
 
 
    // s 和 s1 在棧上的地址，以及 main 在 TEXT 段的地址 
    println!( 
        "s1: {:p}, s2: {:p}, main(): {:p}", 
        &s1, &s2, main as *const () 
    ); 
    // trait object(s / Display) 的 ptr 地址和 vtable 地址 
    println!("addr1: 0x{:x}, vtable1: 0x{:x}", addr1, vtable1); 
    // trait object(s / Debug) 的 ptr 地址和 vtable 地址 
    println!("addr2: 0x{:x}, vtable2: 0x{:x}", addr2, vtable2); 
 
 
    // trait object(s1 / Display) 的 ptr 地址和 vtable 地址 
    println!("addr3: 0x{:x}, vtable3: 0x{:x}", addr3, vtable3); 
 
 
    // trait object(s1 / Display) 的 ptr 地址和 vtable 地址 
    println!("addr4: 0x{:x}, vtable4: 0x{:x}", addr4, vtable4); 
 
 
    // 指向同一個數(shù)據(jù)的 trait object 其 ptr 地址相同 
    assert_eq!(addr1, addr2); 
    assert_eq!(addr3, addr4); 
 
 
    // 指向同一種類型的同一個 trait 的 vtable 地址相同 
    // 這里都是 String + Display 
    assert_eq!(vtable1, vtable3); 
    // 這里都是 String + Debug 
    assert_eq!(vtable2, vtable4); 
} 

結(jié)果令人驚喜：String + Display 生成的 trait object，和 String + Debug 生成的 trait object，使用的是不同的 vtable：

s1: 0x7ffc7d427a08, s2: 0x7ffc7d427a20, main(): 0x561b76ff2e90 
addr1: 0x7ffc7d427a08, vtable1: 0x561b7702d3b8 
addr2: 0x7ffc7d427a08, vtable2: 0x561b7702d3d8 
addr3: 0x7ffc7d427a20, vtable3: 0x561b7702d3b8 
addr4: 0x7ffc7d427a20, vtable4: 0x561b7702d3d8 

所以，我們可以確定， 虛表是每個 (Trait, Type) 一份，在編譯時就生成好了 。

那么，編譯器在什么時機來生成這張?zhí)摫砟兀坑欣碛赏茢啵诰幾g器編譯 impl 某個 trait 的代碼時生成了虛表，比如：

impl Debug for String {...} 

因為此時編譯器有生成虛表所需要的一切信息：

• 數(shù)據(jù)如何銷毀：String 的 drop 方法的地址此時需要已經(jīng)編譯得出
• 數(shù)據(jù)的大小和對齊：此刻是 String 類型，所以大小 24 字節(jié)，對齊 8 字節(jié)
• trait 方法：在編譯 impl Debug 時就已經(jīng)得到 fmt() 方法的地址

如果我是編譯器的開發(fā)者，此時不做，更待何時？所以我們可以做出這個推斷。這個推斷邏輯自洽，看上去非常合理，大概率是對的。不過要驗證起來不那么容易，除非我們繼續(xù)在 Rust 編譯器源碼中做實驗。

從實驗結(jié)果中最終得出結(jié)論

好，綜合上述三個實驗，我們的腦海中，已經(jīng)可以構(gòu)筑出這樣一幅圖：

此刻，我們就完美地找到了一開始的問題我們想要的答案。對于開頭的問題，我是這么回答的：

好問題。這個在講 trait 的那一課有講到。虛表在每個 impl TraitA for TypeB {} 實現(xiàn)時就會編譯出一份。比如 String 的 Debug 實現(xiàn), String 的 Display 實現(xiàn)各有一份虛表，它們在編譯時就生成并放在了二進制文件中（大概是 RODATA 段中）。 所以虛表是每個 (Trait, Type) 一份。并且在編譯時就生成好了。 如果你感興趣，可以在 playground 里運行這段代碼（這是后面講 trait 時使用的代碼）： https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=89311eb50772982723a39b23874b20d6 。限于篇幅，代碼就不貼了。

因為我自己通過做實驗，找到了答案，所以，我對自己的結(jié)論和推斷都很有信心。同時，因為這是我自己探索出來的知識，我并非借用別人腦海中的想法，而是對它擁有所有權(quán)，所以，我可以自如地從各個角度來構(gòu)筑我的答案。

小結(jié)

在韋氏詞典中，是這么定義科學(xué)方法的：科學(xué)方法是一種有系統(tǒng)地尋求知識的程序，涉及了以下三個步驟：問題的認(rèn)知與表述、實驗數(shù)據(jù)的收集、假說的構(gòu)成與測試。我們在探索 Rust 的 vtable 是如何構(gòu)建的過程中，使用了科學(xué)方法。它是一個不斷迭代的過程，從觀測開始，一路經(jīng)歷問問題，做出假設(shè)，構(gòu)建實驗來驗證假設(shè)，觀察實驗結(jié)果，提出新的問題，進一步迭代下去，直到我們形成了一個自洽的理論：

本文我們通過一個 Rust 的例子來探討這個方法。當(dāng)這個方法本身跟 Rust 無關(guān)。我們在學(xué)習(xí)編程語言，使用第三方庫，構(gòu)建復(fù)雜的系統(tǒng)，都可以用這個方法。如果你能夠掌握和使用這個方法，那么，慢慢地你就能成為知識的所有者。