抽象化に逃げないという選択

抽象化は強力だ。強力すぎて、ときどき「逃げ場」になる。

抽象化が逃げ場になるとき

良い抽象化は、複雑さを覆い隠して、上のレイヤを楽にしてくれる。だが「楽にしてくれる」と「考えなくていい」は違う。

詰まったときに「ライブラリの中のことだから」と手を止める。遅いのに「フレームワークがよしなにやってる」で済ませる。このとき抽象化は、複雑さを隠す道具ではなく、向き合わない口実になっている。

隠された層を、開けて見る

私はときどき、抽象を一段はがして下を覗くことにしている。たとえば /proc/self/maps を開けば、プロセスのメモリ空間がそのまま並んでいる。

$ cat /proc/self/maps | head -4
55a3c1e00000-55a3c1e21000 r--p 00000000 fe:01 1835 /usr/bin/cat
55a3c1e21000-55a3c1f0a000 r-xp 00021000 fe:01 1835 /usr/bin/cat
7f9c2a000000-7f9c2a200000 rw-p 00000000 00:00 0
7f9c2a200000-7f9c2a201000 ---p 00000000 00:00 0

mmap でマップされた領域、ヒープ、共有ライブラリ。普段はアロケータと仮想メモリの抽象に隠れているものが、ここでは生のアドレス範囲として見える。「よしなに」の中身を、いちど自分の目で確かめておく。

断片化は、抽象の下でしか直せない

長く動くサービスでメモリが下がりきらないとき、原因はたいてい断片化だ。そしてこれは、抽象のレイヤからは絶対に直せない。

マップを眺め、確保と解放のパターンを追い、どの領域が虫食いになっているかを自分で突き止める。抽象に逃げていたら、ここには永遠にたどり着けない。

逃げない、を設計の前提にする

抽象化を否定したいわけではない。むしろ普段は積極的に使う。

ただ、いざというときに一段はがして下を見られること──それを設計の前提に置いておきたい。抽象は便利な道具であって、向き合わなくていい理由にはならない。逃げ場にしない覚悟だけが、抽象化を本当に使いこなす条件なのだと思う。

#mmap #設計