Go1.16引入目錄遍歷優(yōu)化解析

更新時(shí)間：2024年10月01日 16:20:22 作者：apocelipes

Go1.16版本中,對(duì)目錄遍歷進(jìn)行了顯著的優(yōu)化,新增的接口os.ReadDir、(*os.File).ReadDir和filepath.WalkDir使用fs.DirEntry代替os.FileInfo,減少了系統(tǒng)調(diào)用次數(shù),提高了遍歷效率,測(cè)試顯示,優(yōu)化后的遍歷速度比原先快了480%

一轉(zhuǎn)眼go1.23都快發(fā)布了，時(shí)間過(guò)得真快。

不過(guò)今天我們把時(shí)間倒流回三年半之前，來(lái)關(guān)注一個(gè)在go1.16引入的關(guān)于處理目錄時(shí)的優(yōu)化。

對(duì)于go1.16的新變化，大家印象最深的可能是io包的大規(guī)模重構(gòu)，但這個(gè)重構(gòu)實(shí)際上還引進(jìn)了一個(gè)優(yōu)化，這篇文章要說(shuō)的就是這個(gè)優(yōu)化。

本文默認(rèn)Linux環(huán)境，不過(guò)這個(gè)優(yōu)化在BSD系統(tǒng)上也是通用的。

遍歷目錄時(shí)的優(yōu)化

遍歷目錄是個(gè)很常見(jiàn)的需求，尤其是對(duì)于有大量文件的目錄來(lái)說(shuō)，遍歷的性能直接關(guān)系到了整體程序的性能。

go1.16對(duì)于遍歷目錄增加了幾個(gè)新接口：os.ReadDir，(*os.File).ReadDir，filepath.WalkDir。

這幾個(gè)接口最大的特征是對(duì)目錄項(xiàng)使用fs.DirEntry表示而不是os.FileInfo。fs.DirEntry是一個(gè)接口，它提供了類似os.FileInfo的方法：

type DirEntry interface {
        Name() string
        IsDir() bool
        Type() FileMode
        Info() (FileInfo, error)
}

它還提供了一個(gè)叫Info的方法以便獲得os.FileInfo。

這個(gè)接口有什么神奇的呢？我們看下性能測(cè)試：

func IterateDir(path string) int {
    // go1.16 的 os.ReadDir 就是這么實(shí)現(xiàn)的，為了測(cè)試我們把它展開(kāi)成對(duì)(*os.File).ReadDir的調(diào)用
	f, err := os.Open(path)
	if err != nil {
		panic(err)
	}
	defer f.Close()
 
	files, err := f.ReadDir(-1)
	if err != nil {
		panic(err)
	}
	length := 0
	for _, finfo := range files {
		length = max(length, len(finfo.Name()))
	}
	return length
}
 
func IterateDir2(path string) int {
    // 1.16之前遍歷目錄的常用方法之一
	f, err := os.Open(path)
	if err != nil {
		panic(err)
	}
	defer f.Close()
 
	files, err := f.Readdir(-1)
	if err != nil {
		panic(err)
	}
	length := 0
	for _, finfo := range files {
		length = max(length, len(finfo.Name()))
	}
	return length
}
 
func BenchmarkIter1(b *testing.B) {
	for range b.N {
		IterateDir("../test")
	}
}
 
func BenchmarkIter2(b *testing.B) {
	for range b.N {
		IterateDir2("../test")
	}
}

test目錄是一個(gè)有5000個(gè)文件的位于Btrfs文件系統(tǒng)上的目錄，我們的測(cè)試用例會(huì)遍歷目錄并找出名字最長(zhǎng)的文件的文件名長(zhǎng)度。

這是測(cè)試結(jié)果：

可以看到優(yōu)化后的遍歷比原先的快了480%。換了個(gè)函數(shù)為什么就會(huì)有這么大的提升？想知道答案的話就繼續(xù)看吧。

優(yōu)化的原理

繼續(xù)深入前我們先看看老的接口是怎么獲取到目錄里的文件信息的。答案是遍歷目錄拿到路徑，然后調(diào)用os.Lstat獲取完整的文件信息：

func (f *File) Readdir(n int) ([]FileInfo, error) {
	if f == nil {
		return nil, ErrInvalid
	}
	_, _, infos, err := f.readdir(n, readdirFileInfo)
	if infos == nil {
		// Readdir has historically always returned a non-nil empty slice, never nil,
		// even on error (except misuse with nil receiver above).
		// Keep it that way to avoid breaking overly sensitive callers.
		infos = []FileInfo{}
	}
	return infos, err
}

這個(gè)f.readdir會(huì)根據(jù)第二個(gè)參數(shù)的值來(lái)改變自己的行為，根據(jù)值不同它會(huì)遵循1.16前老代碼的行為或者采用新的優(yōu)化方法。這個(gè)函數(shù)不同系統(tǒng)上的實(shí)現(xiàn)也不同，我們選則*nix系統(tǒng)上的實(shí)現(xiàn)看看：

func (f *File) readdir(n int, mode readdirMode) (names []string, dirents []DirEntry, infos []FileInfo, err error) {
	...
 
	for n != 0 {
		// 使用系統(tǒng)調(diào)用獲得目錄項(xiàng)的數(shù)據(jù)
        // 目錄項(xiàng)的元信息一般是存儲(chǔ)在目錄本身的數(shù)據(jù)里的，所以讀這些信息和讀普通文件很類似
		if d.bufp >= d.nbuf {
			d.bufp = 0
			var errno error
			d.nbuf, errno = f.pfd.ReadDirent(*d.buf)
			runtime.KeepAlive(f)
			if errno != nil {
				return names, dirents, infos, &PathError{Op: "readdirent", Path: f.name, Err: errno}
			}
			if d.nbuf <= 0 {
				break // EOF
			}
		}
 
		buf := (*d.buf)[d.bufp:d.nbuf]
		reclen, ok := direntReclen(buf)
		if !ok || reclen > uint64(len(buf)) {
			break
		}
        // 注意這行
		rec := buf[:reclen]
 
		if mode == readdirName {
			names = append(names, string(name))
		} else if mode == readdirDirEntry {
			// 這里的代碼后面再看
		} else {
			info, err := lstat(f.name + "/" + string(name))
			if IsNotExist(err) {
				// File disappeared between readdir + stat.
				// Treat as if it didn't exist.
				continue
			}
			if err != nil {
				return nil, nil, infos, err
			}
			infos = append(infos, info)
		}
	}
 
	if n > 0 && len(names)+len(dirents)+len(infos) == 0 {
		return nil, nil, nil, io.EOF
	}
	return names, dirents, infos, nil
}

ReadDirent對(duì)應(yīng)的是Linux上的系統(tǒng)調(diào)用getdents，這個(gè)系統(tǒng)調(diào)用會(huì)把目錄的目錄項(xiàng)信息讀取到一塊內(nèi)存里，之后程序可以解析這塊內(nèi)存里的數(shù)據(jù)來(lái)獲得目錄項(xiàng)的一些信息，這些信息一般包括了文件名，文件的類型，文件是否是目錄等信息。

老代碼在讀取完這些信息后會(huì)利用文件名再次調(diào)用lstat，這個(gè)也是系統(tǒng)調(diào)用，可以獲取更完整的文件信息，包括了文件的擁有者，文件的大小，文件的修改日期等。

老的代碼有啥問(wèn)題呢？大的問(wèn)題不存在，接口也算易用，但有些小瑕疵：

大多數(shù)時(shí)間遍歷目錄主要是要獲得目錄中文件的名字或者類型等屬性，顯然os.FileInfo返回的信息過(guò)多了。這些用不著的信息會(huì)浪費(fèi)不少內(nèi)存，獲取這些信息也需要額外花時(shí)間——lstat需要去進(jìn)行磁盤(pán)io才能得到這些信息，而目錄里的文件不像目錄項(xiàng)信息那樣緊密的存儲(chǔ)在一起，它們是分散的，所以一一讀取它們的元信息帶來(lái)的負(fù)擔(dān)會(huì)很大。使用的系統(tǒng)調(diào)用太多了。由于我們測(cè)試目錄的文件很多，但getdents可能要調(diào)用多次，這里假設(shè)為兩次好了。對(duì)于每一個(gè)目錄項(xiàng)，都需要用lstat去獲取文件的詳細(xì)信息，這樣又有5000次系統(tǒng)調(diào)用，加起來(lái)是5002次。系統(tǒng)調(diào)用的開(kāi)銷是很大的，積累到5000多次則會(huì)帶來(lái)肉眼可見(jiàn)的性能下降。實(shí)際上linux本身對(duì)lstat有優(yōu)化，不會(huì)真的出現(xiàn)要反復(fù)進(jìn)入系統(tǒng)調(diào)用5000次的情況，但幾十到上百次還是需要的。

優(yōu)化的代碼其實(shí)只改了一行，是f.readdir(n, readdirDirEntry)，第二個(gè)參數(shù)變了。新代碼會(huì)走上面注釋掉的那段邏輯：

// rec := buf[:reclen] 防止你忘了rec是哪來(lái)的
de, err := newUnixDirent(f.name, string(name), direntType(rec))
if IsNotExist(err) {
	// File disappeared between readdir and stat.
	// Treat as if it didn't exist.
	continue
}
if err != nil {
	return nil, dirents, nil, err
}
dirents = append(dirents, de)

取代lstat的是函數(shù)newUnixDirent，這個(gè)函數(shù)可以不依賴額外的系統(tǒng)調(diào)用獲取文件的一部分元數(shù)據(jù)：

type unixDirent struct {
	parent string
	name   string
	typ    FileMode
	info   FileInfo
}
 
func newUnixDirent(parent, name string, typ FileMode) (DirEntry, error) {
	ude := &unixDirent{
		parent: parent,
		name:   name,
		typ:    typ,
	}
    // 檢測(cè)文件類型信息是否有效
	if typ != ^FileMode(0) && !testingForceReadDirLstat {
		return ude, nil
	}
 
	info, err := lstat(parent + "/" + name)
	if err != nil {
		return nil, err
	}
 
	ude.typ = info.Mode().Type()
	ude.info = info
	return ude, nil
}

文件名和類型都是在解析目錄項(xiàng)時(shí)就得到的，因此直接設(shè)置就行。不過(guò)不是每個(gè)文件系統(tǒng)都支持在目錄項(xiàng)數(shù)據(jù)里存儲(chǔ)文件類型，所以代碼里做了回退，一旦發(fā)現(xiàn)文件類型是無(wú)效數(shù)據(jù)就會(huì)使用lstat重新獲取信息。

如果只使用文件名和文件的類型這兩個(gè)信息，那么整個(gè)遍歷的邏輯流程到這就結(jié)束了，文件系統(tǒng)提供支持的情況下不需要調(diào)用lstat。所以整個(gè)遍歷只需要兩次系統(tǒng)調(diào)用。這就是為什么優(yōu)化方案會(huì)快接近五倍的原因。

對(duì)于要使用其他信息比如文件大小的用戶，優(yōu)化方案實(shí)際上也有好處，因?yàn)楝F(xiàn)在lstat是延遲且按需調(diào)用的：

func (d *unixDirent) Info() (FileInfo, error) {
	if d.info != nil {
		return d.info, nil
	}
    // 只會(huì)調(diào)用一次
	return lstat(d.parent + "/" + d.name)
}

這樣也能盡量減少不必要的系統(tǒng)調(diào)用。

所以整體優(yōu)化的原理是：盡量充分利用文件系統(tǒng)本身提供的信息+減少系統(tǒng)調(diào)用。要遍歷的目錄越大優(yōu)化的效果也越明顯。

優(yōu)化的支持情況

上面也說(shuō)了，能做到優(yōu)化需要文件系統(tǒng)把文件類型信息存儲(chǔ)在目錄的目錄項(xiàng)數(shù)據(jù)里。這個(gè)需要文件系統(tǒng)的支持。

如果文件系統(tǒng)不支持的話最后還是需要依賴lstat去讀取具體文件的元數(shù)據(jù)。

不同文件系統(tǒng)的信息實(shí)在太分散，還有不少過(guò)時(shí)的，所以我花了幾天看代碼+查文檔做了下整理：

btrfs，ext2，ext4：這個(gè)幾個(gè)文件系統(tǒng)支持優(yōu)化，man pages加文件系統(tǒng)代碼都能證實(shí)這一點(diǎn)
OpenZFS：這個(gè)文件系統(tǒng)不在Linux內(nèi)核里，所以man pages里沒(méi)提到，但也支持優(yōu)化
xfs：支持優(yōu)化，但得在創(chuàng)建文件系統(tǒng)時(shí)使用類似mkfs.xfs -f -n ftype=1的選項(xiàng)才行
F2FS，EROFS：文檔沒(méi)提過(guò)，但看內(nèi)核的代碼里是支持的，代碼的位置在xxx_readdir這個(gè)函數(shù)附近。
fat32，exfat：文檔沒(méi)提過(guò)，但看內(nèi)核代碼發(fā)現(xiàn)是支持的，不過(guò)fat家族的文件類型沒(méi)有那么多花樣，只有目錄和普通文件這兩種，所以代碼里很粗暴的判斷目錄項(xiàng)是否設(shè)置了dir標(biāo)志，有就是目錄沒(méi)有統(tǒng)統(tǒng)算普通文件。這么做倒是正常的，因?yàn)閒at本來(lái)就不支持別的文件類型，畢竟這個(gè)文件系統(tǒng)連軟鏈接都不支持，更不用指望Unix Domain Socket和命名管道了。
ntfs：支持，然而如注釋所說(shuō)，因?yàn)閚tfs和其他文件系統(tǒng)處理type的方式不一樣，導(dǎo)致雖然文件系統(tǒng)本身支持大部分文件類型，但type信息里只能獲得文件是不是目錄。所以它后面對(duì)于不是目錄的文件會(huì)去磁盤(pán)上讀取文件的inode然后再?gòu)膇node里獲取文件類型——實(shí)際上相當(dāng)于執(zhí)行了一次lstat，相比lstat減少了進(jìn)入系統(tǒng)調(diào)用時(shí)的一次上下文切換，所以ntfs上優(yōu)化效果會(huì)不如其他文件系統(tǒng)。

這么一看的話基本上主流的常見(jiàn)的文件系統(tǒng)都支持這種優(yōu)化。

這也是為什么go1.16會(huì)引入這個(gè)優(yōu)化，不僅支持廣泛而且提升很大，免費(fèi)的加速誰(shuí)不愛(ài)呢。

別的語(yǔ)言里怎么利用這個(gè)優(yōu)化

看到這里，你應(yīng)該發(fā)現(xiàn)這個(gè)優(yōu)化其實(shí)是系統(tǒng)層面的，golang只不過(guò)是適配了一下而已。

確實(shí)是這樣的，所以這個(gè)優(yōu)化不光golang能吃到，c/c++/python都行。

先說(shuō)說(shuō)c里怎么利用：直接用系統(tǒng)提供的readdir函數(shù)就行，這個(gè)函數(shù)會(huì)調(diào)用getdents，然后就能自然吃到優(yōu)化了。注意事項(xiàng)和go的一樣，需要檢測(cè)文件系統(tǒng)是否支持設(shè)置d_type。

c++：和c一樣，另外libstdc++的filesystem就是拿readdir實(shí)現(xiàn)的，所以用filesystem標(biāo)準(zhǔn)庫(kù)也能獲得優(yōu)化：

// https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/src/filesystem/dir-common.h#L270
inline file_type
get_file_type(const std::filesystem::__gnu_posix::dirent& d [[gnu::unused]])
{
#ifdef _GLIBCXX_HAVE_STRUCT_DIRENT_D_TYPE
  switch (d.d_type)
  {
  case DT_BLK:
    return file_type::block;
  case DT_CHR:
    return file_type::character;
  case DT_DIR:
    return file_type::directory;
  case DT_FIFO:
    return file_type::fifo;
  case DT_LNK:
    return file_type::symlink;
  case DT_REG:
    return file_type::regular;
  case DT_SOCK:
    return file_type::socket;
  case DT_UNKNOWN:
    return file_type::unknown;
  default:
    return file_type::none;
  }
#else
  return file_type::none;
#endif
}
 
// 如果操作系統(tǒng)以及文件系統(tǒng)不支持，則回退到lstat
// https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/fs_dir.h#L342
file_type
_M_file_type() const
{
    if (_M_type != file_type::none && _M_type != file_type::symlink)
	    return _M_type;
    return status().type();
}

唯一的區(qū)別在于如果目標(biāo)文件是軟連接，也會(huì)調(diào)用stat。

python：使用os.scandir可以獲得優(yōu)化，底層和c一樣使用readdir：https://github.com/python/cpython/blob/main/Modules/posixmodule.c#L16211，實(shí)現(xiàn)方法甚至類名都和golang很像，代碼就不貼了。