Windows 上折騰 CMU15445 這門數(shù)據(jù)庫系統(tǒng)課的實(shí)驗(yàn)環(huán)境是很多人入門階段第一個(gè)真正的攔路虎。課程官方給的是 Linux 環(huán)境下的構(gòu)建流程而大部分人的主力機(jī)是 Windows直接硬上要么編譯工具鏈對不上要么某些系統(tǒng)調(diào)用行為不一致跑著跑著就卡在莫名其妙的鏈接錯(cuò)誤上。我前后在幾臺(tái)不同配置的機(jī)器上搭過這套環(huán)境也幫身邊同學(xué)遠(yuǎn)程排查過不少次最后穩(wěn)定下來的方案就是走 WSL 這條路——在 Windows 11 里跑一個(gè)輕量的 Linux 子系統(tǒng)把課程需要的編譯工具鏈、依賴庫、調(diào)試器全部裝進(jìn)去Windows 這邊只負(fù)責(zé)編輯代碼和開終端。這篇內(nèi)容面向的是準(zhǔn)備做 2024Spring 版本實(shí)驗(yàn)、但卡在環(huán)境搭建這一步的同學(xué)不管你之前有沒有用過 WSL、熟不熟悉 CMake都能照著走通。我會(huì)把每一步為什么這么做講清楚把那些官方文檔里不會(huì)寫、但實(shí)際一操作就會(huì)撞上的坑提前擺出來包括 WSL 版本選擇、目錄放在哪、依賴裝哪些、編譯報(bào)錯(cuò)怎么定位這些具體問題。整套流程走完你應(yīng)該能得到一個(gè)能正常cmake、能跑單元測試、能掛調(diào)試器的開發(fā)環(huán)境后面專心寫 Buffer Pool 和 B 樹就行。1. 為什么這套實(shí)驗(yàn)在 Windows 原生環(huán)境下容易翻車先把這件事的底層邏輯說清楚不然很多人會(huì)誤以為是自己的操作問題。CMU15445 的實(shí)驗(yàn)代碼是一套 C 工程依賴 CMake 構(gòu)建、Google Test 做單元測試、還有若干第三方庫比如用于 JSON 解析的庫、用于并發(fā)的組件。這套東西的設(shè)計(jì)前提就是 POSIX 環(huán)境也就是類 Unix 系統(tǒng)的那套文件、進(jìn)程、線程語義。Windows 原生環(huán)境的問題不在于能不能裝編譯器而在于語義差異。舉個(gè)最典型的例子課程代碼里大量使用std::thread、互斥鎖、條件變量來做并發(fā)控制這些在 Linux 上的 pthread 實(shí)現(xiàn)和 Windows 上的線程模型雖然標(biāo)準(zhǔn)庫層面做了抽象但底層行為、調(diào)度時(shí)機(jī)、甚至某些邊界條件下的表現(xiàn)并不完全一致。你在 Windows 上跑單元測試可能出現(xiàn) Linux 上根本不會(huì)出現(xiàn)的偶發(fā)失敗排查起來極其痛苦因?yàn)槟惴植磺迨亲约捍a寫錯(cuò)了還是平臺(tái)差異導(dǎo)致的。再一個(gè)是構(gòu)建工具鏈。課程用的 CMake 腳本里有一些平臺(tái)相關(guān)的判斷邏輯默認(rèn)按 Linux 的路徑和庫名去找依賴。你在 Windows 上用 MSVC 或者 MinGW 去編譯很可能在find_package或者鏈接階段就報(bào)找不到庫。有人試過用 Visual Studio 直接打開結(jié)果 CMake 配置階段就一堆警告和錯(cuò)誤改起來沒完沒了。還有一個(gè)容易被忽略的點(diǎn)文件系統(tǒng)大小寫敏感性。Linux 是大小寫敏感的Windows 默認(rèn)不敏感。課程代碼里如果有#include buffer_pool_manager.h而實(shí)際文件名大小寫有出入在 Windows 上可能蒙混過關(guān)但換到評(píng)測環(huán)境就炸。這種問題在本地開發(fā)時(shí)完全看不出來屬于埋雷。所以結(jié)論很明確與其在 Windows 原生環(huán)境里跟工具鏈和語義差異搏斗不如直接用一個(gè)真正的 Linux 環(huán)境。WSL 就是成本最低的選擇——不用裝雙系統(tǒng)、不用開虛擬機(jī)吃內(nèi)存Windows 11 上的 WSL2 底層是輕量虛擬機(jī)性能和兼容性都?jí)蛴梦募ネㄒ卜奖?。提示不要試圖用 Cygwin 或者 MSYS2 來湊合。這兩個(gè)方案確實(shí)能提供一部分 POSIX 兼容層但面對課程這種涉及線程、內(nèi)存管理、系統(tǒng)調(diào)用的工程兼容層的坑比 WSL 多得多而且社區(qū)里幾乎沒有針對這套實(shí)驗(yàn)的 Cygwin 經(jīng)驗(yàn)可參考出問題只能自己啃。1.1 WSL1 和 WSL2 到底選哪個(gè)這是個(gè)必須一開始就定下來的決策因?yàn)閮烧咔袚Q雖然不算麻煩但裝好的依賴和配置在切換后可能需要重來。WSL1 是系統(tǒng)調(diào)用翻譯層文件系統(tǒng)直接走 Windows 的跨系統(tǒng)訪問文件快但系統(tǒng)調(diào)用兼容性不完整WSL2 是真正的輕量虛擬機(jī)跑的是完整 Linux 內(nèi)核兼容性幾乎和原生 Linux 一致但跨系統(tǒng)訪問文件尤其是從 Linux 側(cè)訪問 Windows 盤符下的文件性能較差。對這套實(shí)驗(yàn)來說答案很明確選 WSL2。原因在于課程代碼涉及大量并發(fā)和內(nèi)存操作WSL1 的翻譯層在某些系統(tǒng)調(diào)用上行為不完整可能出現(xiàn)難以定位的運(yùn)行時(shí)問題。而 WSL2 的完整內(nèi)核能保證 pthread、內(nèi)存映射這些機(jī)制的行為和原生 Linux 一致單元測試結(jié)果可信。代價(jià)是文件訪問性能。這里引出一個(gè)非常關(guān)鍵的實(shí)操建議代碼一定要放在 WSL 自己的文件系統(tǒng)里不要放在 Windows 的盤符下。很多人習(xí)慣在C:\Users\xxx\projects下建工程然后從 WSL 里訪問/mnt/c/...這樣編譯速度會(huì)慢到讓你懷疑人生——因?yàn)槊看挝募x寫都要跨虛擬機(jī)邊界。正確做法是在 WSL 的家目錄下建工程比如~/cmu15445編譯速度能差出好幾倍。1.2 環(huán)境搭建的整體路線圖在動(dòng)手之前先把整條鏈路理清楚避免東一榔頭西一棒子。整體分四步第一步在 Windows 側(cè)啟用 WSL 并裝好一個(gè) Linux 發(fā)行版第二步進(jìn)入 Linux 環(huán)境更新包管理器、裝編譯工具鏈和依賴庫第三步拉取課程代碼配置 CMake 并完成首次構(gòu)建第四步驗(yàn)證環(huán)境跑通單元測試、確認(rèn)調(diào)試器可用。這四步里第一步和第二步是純環(huán)境準(zhǔn)備第三步和第四步才是真正驗(yàn)證這套環(huán)境能不能支撐后續(xù)實(shí)驗(yàn)。很多人卡在第三步的 CMake 配置或者編譯報(bào)錯(cuò)上本質(zhì)是第二步的依賴沒裝全。所以下面我會(huì)把依賴清單列清楚并且解釋每個(gè)依賴是干什么用的這樣你遇到報(bào)錯(cuò)時(shí)能自己判斷缺了什么。2. Windows 側(cè)啟用 WSL 與安裝發(fā)行版的具體操作Windows 11 上啟用 WSL 比早期版本簡單很多一條命令基本搞定但有幾個(gè)前置條件需要確認(rèn)。首先確認(rèn)你的系統(tǒng)版本W(wǎng)SL2 要求 Windows 10 版本 1903 以上或者 Windows 11這個(gè)一般沒問題。其次確認(rèn) CPU 虛擬化在 BIOS 里是開著的WSL2 依賴虛擬化功能如果 BIOS 里關(guān)了裝完也啟動(dòng)不了。最省事的做法是直接用管理員權(quán)限打開 PowerShell執(zhí)行安裝命令。這里有個(gè)細(xì)節(jié)早期需要手動(dòng)啟用適用于 Linux 的 Windows 子系統(tǒng)和虛擬機(jī)平臺(tái)兩個(gè)可選功能然后重啟再設(shè)置默認(rèn)版本為 WSL2。較新的 Windows 11 版本已經(jīng)把這一步合并了一條命令會(huì)自動(dòng)處理啟用功能和安裝默認(rèn)發(fā)行版。wsl --install執(zhí)行完這條命令系統(tǒng)會(huì)自動(dòng)啟用所需功能、下載并安裝 WSL2 內(nèi)核、裝一個(gè)默認(rèn)的 Ubuntu 發(fā)行版然后提示你重啟。重啟后首次進(jìn)入會(huì)要求設(shè)置 Linux 用戶名和密碼這個(gè)用戶名密碼是 Linux 系統(tǒng)內(nèi)部的和 Windows 賬戶無關(guān)記好就行。如果你已經(jīng)裝過 WSL 但不確定版本或者想手動(dòng)控制裝哪個(gè)發(fā)行版可以用下面這組命令。先看當(dāng)前狀態(tài)wsl --status wsl --list --verbose--list --verbose會(huì)列出已安裝的發(fā)行版和它們各自跑的 WSL 版本。如果某個(gè)發(fā)行版顯示 VERSION 是 1需要轉(zhuǎn)成 2wsl --set-version Ubuntu 2轉(zhuǎn)換過程會(huì)花幾分鐘取決于發(fā)行版大小。轉(zhuǎn)完之后再--list --verbose確認(rèn)一下。另外建議把默認(rèn)版本設(shè)成 2這樣以后新裝的發(fā)行版默認(rèn)就是 WSL2wsl --set-default-version 22.1 發(fā)行版選擇與首次進(jìn)入的注意事項(xiàng)默認(rèn)裝的是 Ubuntu對這套實(shí)驗(yàn)來說完全夠用不需要糾結(jié) Debian、Fedora 之類的。Ubuntu 的包管理生態(tài)最成熟網(wǎng)上遇到問題搜到的解決方案也最多。版本上較新的 LTS 版本都行編譯器版本足夠支撐課程代碼的 C 標(biāo)準(zhǔn)要求。首次進(jìn)入 Linux 環(huán)境先做兩件事更新包索引、確認(rèn)基礎(chǔ)工具在。更新這一步別省很多人裝完就直接裝依賴結(jié)果因?yàn)樗饕f導(dǎo)致某些包版本對不上。sudo apt update sudo apt upgrade -yapt upgrade可能會(huì)提示有一些服務(wù)需要重啟或者配置文件沖突一般直接回車用默認(rèn)選項(xiàng)即可。升級(jí)完確認(rèn)一下幾個(gè)基礎(chǔ)工具gcc --version g --version make --version cmake --version如果cmake提示找不到說明還沒裝后面裝依賴時(shí)會(huì)一起處理。這里先確認(rèn) gcc/g 在因?yàn)?Ubuntu 一般自帶。如果連 gcc 都沒有說明這個(gè)發(fā)行版比較精簡需要手動(dòng)裝build-essential。注意WSL 里的 Linux 用戶默認(rèn)不是 root裝軟件要用sudo。如果你在首次設(shè)置時(shí)跳過了密碼設(shè)置某些情況下會(huì)出現(xiàn)可以用sudo passwd重新設(shè)一個(gè)否則后面所有sudo操作都會(huì)卡住。2.2 目錄規(guī)劃工程放哪里決定了你的編譯體驗(yàn)前面提過代碼要放在 WSL 文件系統(tǒng)里這里具體說怎么放。WSL 的家目錄在 Windows 側(cè)可以通過資源管理器訪問路徑大概是\\wsl$\Ubuntu\home\你的用戶名所以放在家目錄下并不影響你用 Windows 的編輯器打開。推薦在 home 下建一個(gè)專門放課程的目錄mkdir -p ~/projects cd ~/projects后續(xù)所有工程都放這個(gè)目錄下。這樣做的另一個(gè)好處是備份和遷移方便——WSL 的整個(gè)文件系統(tǒng)可以導(dǎo)出成鏡像換機(jī)器時(shí)直接導(dǎo)入環(huán)境原樣帶過去。反過來說如果你非要把工程放在/mnt/c/...下編譯時(shí)會(huì)明顯感覺到慢尤其是這套實(shí)驗(yàn)代碼量不小、模板和頭文件依賴多增量編譯的差距會(huì)非常明顯。我實(shí)測過同一個(gè)工程在兩個(gè)位置的完整構(gòu)建時(shí)間差距能到數(shù)倍日常開發(fā)體驗(yàn)完全不是一個(gè)級(jí)別。3. Linux 側(cè)編譯工具鏈與依賴庫的完整清單這一步是整個(gè)環(huán)境搭建的核心依賴裝不全后面 CMake 配置和編譯階段會(huì)以各種看似不相關(guān)的報(bào)錯(cuò)形式暴露出來。我按必需和建議兩檔來列并且說明每個(gè)東西的作用方便你按報(bào)錯(cuò)反查。先裝編譯工具鏈和構(gòu)建工具sudo apt install -y build-essential cmake gitbuild-essential是個(gè)元包包含 gcc、g、make、libc 開發(fā)頭文件等一整套基礎(chǔ)編譯環(huán)境。cmake是構(gòu)建系統(tǒng)課程工程用它來生成 Makefile。git用來拉代碼雖然你也可以在 Windows 側(cè)拉好再拷進(jìn)來但直接在 Linux 里操作更順。然后是這套實(shí)驗(yàn)會(huì)用到的第三方依賴。課程代碼依賴幾個(gè)庫最典型的是用于 JSON 解析的庫和用于測試的 Google Test。Google Test 課程工程一般會(huì)通過 CMake 的 FetchContent 或者子模塊方式引入但有些版本需要系統(tǒng)里預(yù)裝。穩(wěn)妥起見把常見的開發(fā)庫都裝上sudo apt install -y libssl-dev libreadline-dev zlib1g-devlibssl-dev提供加密庫的開發(fā)頭文件某些依賴會(huì)用到libreadline-dev和zlib1g-dev屬于常見的基礎(chǔ)庫裝上避免鏈接階段報(bào)缺庫。這幾個(gè)包體積不大裝了不虧。調(diào)試工具單獨(dú)說。這套實(shí)驗(yàn)后期排查內(nèi)存問題和并發(fā)問題調(diào)試器幾乎是必需品sudo apt install -y gdb valgrindgdb是標(biāo)準(zhǔn)調(diào)試器配合 VS Code 的調(diào)試插件可以圖形化斷點(diǎn)調(diào)試。valgrind用來檢測內(nèi)存泄漏和越界訪問Buffer Pool 那部分實(shí)驗(yàn)里非常有用——你管理的內(nèi)存頁如果釋放邏輯寫錯(cuò)valgrind 能直接指出來。3.1 依賴裝完后如何驗(yàn)證工具鏈完整裝完不要急著拉代碼先做一輪驗(yàn)證把問題擋在編譯之前。驗(yàn)證分三層編譯器能不能正常編譯一個(gè)帶線程的 C 程序、CMake 能不能正常配置一個(gè)最小工程、調(diào)試器能不能掛上。第一層寫個(gè)最小測試程序驗(yàn)證編譯器和線程庫cat /tmp/test_thread.cpp EOF #include iostream #include thread #include vector int main() { std::vectorstd::thread threads; int counter 0; for (int i 0; i 4; i) { threads.emplace_back([counter]() { for (int j 0; j 1000; j) counter; }); } for (auto t : threads) t.join(); std::cout counter counter std::endl; return 0; } EOF g -stdc17 -pthread /tmp/test_thread.cpp -o /tmp/test_thread /tmp/test_thread能編譯通過并輸出結(jié)果說明編譯器和 pthread 鏈接沒問題。注意-pthread這個(gè)參數(shù)課程工程的 CMake 里會(huì)處理線程庫鏈接但你手動(dòng)測試時(shí)要帶上否則會(huì)報(bào)std::thread相關(guān)的鏈接錯(cuò)誤。第二層驗(yàn)證 CMake 能跑通一個(gè)最小工程。這個(gè)其實(shí)拉完課程代碼配置時(shí)自然會(huì)驗(yàn)證但如果你想提前確認(rèn) CMake 本身沒問題可以建個(gè)空目錄放個(gè)最小CMakeLists.txt試一下。第三層驗(yàn)證調(diào)試器隨便編譯一個(gè)帶-g的程序用 gdb 跑一下看能不能斷住這個(gè)后面結(jié)合 VS Code 配置時(shí)再細(xì)說。3.2 一個(gè)容易被忽略的坑默認(rèn)編譯器和 C 標(biāo)準(zhǔn)課程代碼用的是較新的 C 標(biāo)準(zhǔn)C17 及以上而某些 Ubuntu 版本自帶的 g 版本偏老可能對某些特性支持不完整。裝完build-essential后確認(rèn)一下 g 版本g --version如果版本低于 9建議裝個(gè)更新的版本。Ubuntu 的軟件源里通常有多個(gè) g 版本可選比如g-11、g-12。裝完之后可以用update-alternatives切換默認(rèn)版本或者直接在 CMake 配置時(shí)指定編譯器。sudo apt install -y g-12 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-12 100這里update-alternatives的最后一個(gè)數(shù)字是優(yōu)先級(jí)數(shù)字大的優(yōu)先。裝多個(gè)版本時(shí)可以用--config交互式切換sudo update-alternatives --config g提示不要盲目追最新版本。課程代碼在某個(gè)特定編譯器版本上驗(yàn)證過太新的編譯器有時(shí)會(huì)因?yàn)楦鼑?yán)格的標(biāo)準(zhǔn)檢查報(bào)出一些警告甚至錯(cuò)誤。如果遇到莫名其妙的編譯錯(cuò)誤先確認(rèn)是不是編譯器版本太新導(dǎo)致的必要時(shí)降回課程推薦的版本區(qū)間。4. 拉取課程代碼與首次 CMake 構(gòu)建代碼來源這里不展開具體地址你按課程官方渠道獲取即可。拿到代碼后放進(jìn)前面建好的~/projects目錄。進(jìn)入工程根目錄先看一眼目錄結(jié)構(gòu)確認(rèn)有CMakeLists.txt和各個(gè)實(shí)驗(yàn)?zāi)K的子目錄。首次構(gòu)建的標(biāo)準(zhǔn)流程是建一個(gè)獨(dú)立的構(gòu)建目錄然后在里面跑 CMake。這個(gè)習(xí)慣一定要養(yǎng)成——不要在源碼目錄里直接cmake .那樣生成的文件會(huì)和源碼混在一起清理起來麻煩而且容易污染 git 狀態(tài)。cd ~/projects/你的工程目錄 mkdir -p build cd build cmake ..cmake ..這一步會(huì)做依賴檢查、生成構(gòu)建文件。如果前面依賴裝全了這一步應(yīng)該順利通過輸出一堆配置信息。如果報(bào)錯(cuò)重點(diǎn)看報(bào)錯(cuò)信息里提到的找不到的包或者變量名基本能對應(yīng)到缺哪個(gè)依賴。配置成功后開始編譯make -j$(nproc)-j$(nproc)表示用所有可用核心并行編譯能顯著加快速度。nproc會(huì)輸出當(dāng)前環(huán)境的 CPU 核心數(shù)。WSL2 默認(rèn)能用上宿主機(jī)的核心所以并行度一般夠。4.1 CMake 配置階段常見報(bào)錯(cuò)與對應(yīng)處理配置階段最常見的幾類報(bào)錯(cuò)我按出現(xiàn)頻率排一下并給出處理思路。第一類是找不到某個(gè)包報(bào)錯(cuò)形如Could NOT find XXX。這種直接對應(yīng)到缺依賴用apt install裝對應(yīng)的-dev包即可。關(guān)鍵是看懂包名——CMake 報(bào)的包名和 apt 的包名不一定完全一致比如 CMake 找OpenSSLapt 里是libssl-dev。遇到不認(rèn)識(shí)的搜一下CMake 包名 apt 安裝基本能找到對應(yīng)關(guān)系。第二類是編譯器版本或者標(biāo)準(zhǔn)不滿足報(bào)錯(cuò)里會(huì)提到C standard或者某個(gè)特性不支持。處理方式是升級(jí)編譯器或者調(diào)整 CMake 里的標(biāo)準(zhǔn)設(shè)置。課程工程一般會(huì)在CMakeLists.txt里指定標(biāo)準(zhǔn)如果它指定的標(biāo)準(zhǔn)你的編譯器不支持就得升級(jí)編譯器。第三類是路徑或者權(quán)限問題比如某個(gè)目錄不可寫、某個(gè)文件找不到。這種多半是構(gòu)建目錄建錯(cuò)了位置或者從 Windows 側(cè)拷貝文件時(shí)權(quán)限丟了。WSL 里從/mnt/c拷過來的文件可能帶著奇怪的權(quán)限必要時(shí)用chmod修一下或者干脆在 Linux 側(cè)重新拉一份代碼。4.2 編譯階段的鏈接錯(cuò)誤定位思路配置通過但編譯報(bào)錯(cuò)最常見的是鏈接錯(cuò)誤報(bào)錯(cuò)形如undefined reference to XXX。這類錯(cuò)誤的本質(zhì)是編譯器找到了函數(shù)聲明頭文件里有但鏈接階段找不到函數(shù)實(shí)現(xiàn)對應(yīng)的庫沒鏈上或者庫路徑不對。定位思路分三步。第一步看報(bào)錯(cuò)里提到的符號(hào)屬于哪個(gè)庫比如pthread_create屬于 pthread 庫SSL_new屬于 OpenSSL。第二步確認(rèn)這個(gè)庫在系統(tǒng)里裝了沒有用dpkg -l | grep 庫名查。第三步確認(rèn) CMake 里有沒有正確鏈接這個(gè)庫看CMakeLists.txt里的target_link_libraries。課程工程一般已經(jīng)把鏈接配置寫好了如果你遇到鏈接錯(cuò)誤大概率是系統(tǒng)缺庫而不是工程配置問題。少數(shù)情況下是編譯器版本差異導(dǎo)致某些符號(hào)的 mangling 不一致這種比較難搞通常換回課程推薦的編譯器版本能解決。5. 編輯器與調(diào)試器的打通在 Windows 側(cè)高效開發(fā)環(huán)境搭好之后日常開發(fā)的體驗(yàn)取決于編輯器配置。推薦用 VS Code 配合 WSL 插件這樣你在 Windows 側(cè)用熟悉的界面編輯代碼實(shí)際的文件操作和終端都在 WSL 里兼顧體驗(yàn)和性能。裝好 VS Code 后安裝 WSL 擴(kuò)展。然后在 WSL 終端里進(jìn)入工程目錄執(zhí)行code .VS Code 會(huì)自動(dòng)以遠(yuǎn)程模式打開這個(gè)目錄左下角會(huì)顯示當(dāng)前連的是 WSL 環(huán)境。這時(shí)候你裝的 C 擴(kuò)展、CMake 擴(kuò)展都會(huì)在 WSL 側(cè)生效代碼補(bǔ)全、跳轉(zhuǎn)、格式化都能正常工作。調(diào)試配置是重點(diǎn)。VS Code 的 C 調(diào)試需要launch.json針對這套實(shí)驗(yàn)關(guān)鍵是讓調(diào)試器能找到編譯出來的可執(zhí)行文件、能正確設(shè)置工作目錄因?yàn)閱卧獪y試可能依賴相對路徑的資源文件。一個(gè)可用的配置大概長這樣{ version: 0.2.0, configurations: [ { name: Debug Test, type: cppdbg, request: launch, program: ${workspaceFolder}/build/test/你的測試可執(zhí)行文件名, args: [], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [], externalConsole: false, MIMode: gdb, setupCommands: [ { description: Enable pretty-printing for gdb, text: -enable-pretty-printing, ignoreFailures: true } ] } ] }program指向編譯出來的測試可執(zhí)行文件具體路徑看你工程的構(gòu)建輸出位置。cwd設(shè)成工程根目錄這樣測試?yán)镉孟鄬β窂秸屹Y源文件時(shí)不會(huì)出錯(cuò)。-enable-pretty-printing讓 gdb 輸出 STL 容器時(shí)更可讀調(diào)試時(shí)看std::vector、std::unordered_map的內(nèi)容會(huì)方便很多。5.1 用 valgrind 排查內(nèi)存問題的實(shí)操方式Buffer Pool 那部分實(shí)驗(yàn)里內(nèi)存管理是重頭戲頁的分配、回收、替換邏輯寫錯(cuò)很容易造成泄漏或者越界。valgrind 是排查這類問題的利器但用法有講究?；居梅ㄊ侵苯佑盟苣愕臏y試程序valgrind --leak-checkfull --show-leak-kindsall ./build/test/你的測試可執(zhí)行文件--leak-checkfull會(huì)詳細(xì)報(bào)告每一處泄漏的調(diào)用棧--show-leak-kindsall把各種類型的泄漏都列出來。輸出里重點(diǎn)看definitely lost和invalid read/write這兩類——前者是確定的內(nèi)存泄漏后者是越界訪問都是必須修的。有個(gè)細(xì)節(jié)要注意valgrind 跑起來比正常執(zhí)行慢很多所以不要拿它跑整個(gè)測試套件挑單個(gè)失敗的測試用例跑就行。另外 valgrind 對多線程程序的檢測能力有限數(shù)據(jù)競爭這類問題它不一定能抓到那種情況需要?jiǎng)e的工具或者靠代碼審查。注意valgrind 報(bào)告里有時(shí)會(huì)出現(xiàn)一些來自系統(tǒng)庫或者第三方庫的泄漏這些不是你代碼的問題。判斷方法是看調(diào)用棧如果棧頂是你的代碼那就是你的問題如果整條棧都在系統(tǒng)庫里可以忽略。5.2 單元測試的跑法與失敗定位課程工程用 Google Test編譯后會(huì)生成測試可執(zhí)行文件。跑全部測試直接執(zhí)行那個(gè)文件即可但更常用的是按測試套件或者單個(gè)用例過濾尤其是調(diào)試階段。# 跑全部 ./build/test/測試可執(zhí)行文件 # 只跑某個(gè)測試套件 ./build/test/測試可執(zhí)行文件 --gtest_filterBufferPoolManagerTest.* # 跑單個(gè)用例 ./build/test/測試可執(zhí)行文件 --gtest_filterBufferPoolManagerTest.SampleTest--gtest_filter支持通配符用起來很靈活。測試失敗時(shí)輸出會(huì)告訴你哪個(gè)斷言掛了、期望值和實(shí)際值分別是什么結(jié)合調(diào)試器斷到失敗的那一行基本能定位問題。一個(gè)實(shí)操心得測試失敗時(shí)先別急著改代碼先確認(rèn)這個(gè)失敗是不是穩(wěn)定復(fù)現(xiàn)。并發(fā)相關(guān)的測試有時(shí)會(huì)因?yàn)檎{(diào)度時(shí)機(jī)偶發(fā)失敗多跑幾次看是否穩(wěn)定。如果時(shí)好時(shí)壞大概率是并發(fā)邏輯有問題而不是測試本身的問題。6. 環(huán)境穩(wěn)定性維護(hù)與幾個(gè)反復(fù)踩到的坑環(huán)境搭好只是開始用一段時(shí)間后可能會(huì)遇到一些退化問題這里集中說幾個(gè)我反復(fù)踩到的。第一個(gè)是 WSL 磁盤占用越來越大。WSL2 的虛擬磁盤文件會(huì)隨著使用增長但刪除文件后它不會(huì)自動(dòng)收縮。時(shí)間長了可能占掉幾十 GB。處理方式是定期手動(dòng)壓縮先關(guān)掉 WSL然后用 Windows 側(cè)的 diskpart 或者 PowerShell 命令壓縮虛擬磁盤。具體命令網(wǎng)上能查到核心是先wsl --shutdown再對對應(yīng)的 vhdx 文件做 compact 操作。第二個(gè)是依賴庫版本漂移。Ubuntu 的軟件源會(huì)更新某次apt upgrade之后某個(gè)庫的大版本變了可能導(dǎo)致原本能編譯的工程突然報(bào)錯(cuò)。避免方式是在環(huán)境穩(wěn)定后不要頻繁做全量升級(jí)尤其是臨近實(shí)驗(yàn)截止日期時(shí)。如果確實(shí)需要升級(jí)先在一個(gè)副本環(huán)境里驗(yàn)證。第三個(gè)是文件權(quán)限問題。從 Windows 側(cè)往 WSL 里拷文件或者用某些工具同步文件可能導(dǎo)致文件權(quán)限變成所有人可讀寫甚至可執(zhí)行g(shù)it 會(huì)把這些權(quán)限變化當(dāng)成修改。處理方式是配置 git 忽略文件模式變化git config core.fileMode false這樣 git 就不再把權(quán)限變化當(dāng)成文件修改避免一堆莫名其妙的 diff。6.1 編譯緩存與增量構(gòu)建的清理策略CMake 工程的增量構(gòu)建有時(shí)會(huì)因?yàn)榫彺娌灰恢鲁鰡栴}典型表現(xiàn)是改了代碼但編譯結(jié)果沒變或者報(bào)一些奇怪的文件已存在錯(cuò)誤。遇到這種情況最干脆的辦法是清掉構(gòu)建目錄重新來rm -rf build mkdir build cd build cmake .. make -j$(nproc)這套操作雖然要重新全量編譯但能排除掉絕大多數(shù)緩存導(dǎo)致的問題。日常開發(fā)中如果只是改了源碼正常make增量編譯就行不需要每次清緩存。判斷標(biāo)準(zhǔn)是如果增量編譯的結(jié)果和預(yù)期不符或者報(bào)錯(cuò)信息明顯不合理就清緩存重來。另外 CMake 有個(gè)--fresh參數(shù)較新版本支持可以在保留構(gòu)建目錄的同時(shí)重新配置比整個(gè)刪掉溫和一些。不過對這套實(shí)驗(yàn)來說構(gòu)建目錄里沒什么需要保留的東西直接刪了重建最省心。6.2 內(nèi)存與 CPU 資源分配的調(diào)整WSL2 默認(rèn)會(huì)占用宿主機(jī)相當(dāng)一部分內(nèi)存如果宿主機(jī)內(nèi)存不大可能影響 Windows 側(cè)的日常使用?？梢栽?Windows 用戶目錄下建一個(gè).wslconfig文件來限制資源[wsl2] memory8GB processors4 swap2GBmemory限制 WSL 最多用多少內(nèi)存processors限制用幾個(gè)核心swap是交換空間大小。改完這個(gè)文件后要wsl --shutdown再重新進(jìn)入才生效。對這套實(shí)驗(yàn)來說8GB 內(nèi)存和 4 個(gè)核心一般夠用編譯和跑測試都不會(huì)太吃力。如果你的機(jī)器配置高可以適當(dāng)放寬。這里有個(gè)權(quán)衡限制太緊會(huì)導(dǎo)致編譯慢、測試跑不動(dòng)限制太松又影響宿主機(jī)。建議先按默認(rèn)跑觀察一下任務(wù)管理器里 WSL 的內(nèi)存占用再?zèng)Q定要不要限制。編譯高峰期內(nèi)存占用會(huì)明顯上升留夠余量比較穩(wěn)妥。7. 從環(huán)境搭建到實(shí)驗(yàn)推進(jìn)的銜接建議環(huán)境通了之后建議先別急著寫實(shí)驗(yàn)代碼花點(diǎn)時(shí)間把工程結(jié)構(gòu)和構(gòu)建流程摸熟。具體做法是找到每個(gè)實(shí)驗(yàn)?zāi)K對應(yīng)的目錄看看里面的頭文件和源文件組織方式跑一遍該模塊的單元測試確認(rèn)測試框架能正常工作。這一步能幫你建立對工程的整體認(rèn)知后面寫代碼時(shí)知道該改哪個(gè)文件、測試怎么加。另外建議在開始每個(gè)實(shí)驗(yàn)前先完整跑一遍該實(shí)驗(yàn)的測試記錄下初始通過率。課程工程通常會(huì)給一些未實(shí)現(xiàn)的接口留空初始狀態(tài)下部分測試是失敗的這是正常的。你后續(xù)的工作就是讓這些失敗的測試逐個(gè)通過。有了初始基線你就能清楚知道自己改動(dòng)的效果。調(diào)試習(xí)慣上我個(gè)人的經(jīng)驗(yàn)是遇到測試失敗先用--gtest_filter單獨(dú)跑那個(gè)用例確認(rèn)能穩(wěn)定復(fù)現(xiàn)然后掛調(diào)試器斷到失敗點(diǎn)看變量狀態(tài)如果涉及內(nèi)存問題再上 valgrind。這個(gè)順序能覆蓋絕大多數(shù)問題比盲目改代碼試錯(cuò)高效得多。最后說一個(gè)心態(tài)上的事。環(huán)境搭建這一步看起來繁瑣但它其實(shí)是整個(gè)實(shí)驗(yàn)過程中最標(biāo)準(zhǔn)化的部分——所有問題都有確定的解法不像后面的算法設(shè)計(jì)那樣需要反復(fù)權(quán)衡。把這一步走扎實(shí)后面寫代碼時(shí)就不會(huì)被環(huán)境問題干擾能專心在數(shù)據(jù)結(jié)構(gòu)和管理策略上。我見過不少人環(huán)境沒搭利索就急著寫代碼結(jié)果每次編譯報(bào)錯(cuò)都分不清是環(huán)境問題還是代碼問題白白浪費(fèi)大量時(shí)間。磨刀不誤砍柴工這話在這套實(shí)驗(yàn)上體現(xiàn)得特別明顯。