配列&コレクション

【C#】HashtableとDictionaryの違いを初心者にもわかりやすく比較！型安全・速度・例外処理まで

2025-05-08更新日: 2025-05-08

Dictionary<TKey, TValue>はジェネリックで型安全、ボクシングが不要なぶん高速で、存在しないキーを読むとKeyNotFoundExceptionになります。

一方Hashtableは非ジェネリックで型変換コストがかかり、見つからないキーにはnullを返します。

新規開発ではDictionaryの採用が無難です。

目次から探す

使いどころの全体像
- 代表的な利用シナリオ
- 選択基準の早見表
データ構造と内部実装の比較
型安全性とジェネリクス
- コンパイル時の型チェック
- ボクシング／アンボクシングによる影響
パフォーマンス比較
例外と戻り値の挙動
スレッドセーフ性
容量管理とリサイズ
イテレーションと列挙子
キーのハッシュコード実装
セキュリティ観点
- ハッシュ衝突攻撃への耐性
- シリアライズ／デシリアライズ時のリスク
互換性と移行戦略
よくある落とし穴
ユースケース別の採用判断
代替コレクションとの比較
今後の .NET エコシステム動向
- ランタイム最適化の新機能
- コレクション API 拡張計画
まとめ

使いどころの全体像

C#でデータをキーと値のペアで管理したい場合、HashtableとDictionary<TKey, TValue>のどちらを使うか迷うことがあります。

両者は似た役割を持つコレクションですが、使いどころや特徴が異なります。

ここでは、まずそれぞれの代表的な利用シナリオを紹介し、どのような基準で選べばよいかをわかりやすくまとめます。

代表的な利用シナリオ

Hashtableの利用シーン

Hashtableは.NET Frameworkの初期から存在する非ジェネリックなコレクションです。

以下のようなケースで使われることがあります。

レガシーコードの保守や改修

古いプロジェクトやライブラリでHashtableが使われている場合、互換性のためにそのまま使い続けることがあります。

キーや値の型が不定で、型安全性をあまり気にしない場合

例えば、複数の異なる型のオブジェクトを混在させて格納したいときに、object型として扱えるHashtableが便利なことがあります。

簡単な一時的なデータ格納

型を厳密に管理しなくてもよい簡単な用途で、すぐに使いたい場合に使われることがあります。

ただし、これらのケースでも新規開発ではDictionary<TKey, TValue>の利用が推奨されます。

Dictionary<TKey, TValue>の利用シーン

Dictionary<TKey, TValue>はジェネリックコレクションで、型安全性とパフォーマンスに優れています。

以下のような場面で特に適しています。

新規開発やモダンなコードベース

キーと値の型を明確に指定できるため、バグを減らしやすく、保守性も高いです。

パフォーマンスが重要な処理

ボクシングやアンボクシングが発生しないため、特に値型を扱う場合に高速です。

型安全性を重視する場合

コンパイル時に型チェックが行われるため、実行時の型エラーを防げます。

例外処理を明確にしたい場合

存在しないキーにアクセスしたときに例外が発生するため、エラー検出がしやすいです。

マルチスレッド環境での利用を検討する場合

Dictionary<TKey, TValue>自体はスレッドセーフではありませんが、ConcurrentDictionary<TKey, TValue>などの代替が用意されています。

選択基準の早見表

以下の表は、HashtableとDictionary<TKey, TValue>の特徴を比較し、どちらを選ぶべきかの目安を示しています。

項目	Hashtable	Dictionary<TKey, TValue>
型安全性	なし(object型で格納)	あり(ジェネリックで型指定可能)
パフォーマンス	低め(ボクシング・アンボクシングあり)	高め(型変換不要)
例外処理	存在しないキーは`null`を返す	存在しないキーは`KeyNotFoundException`をスロー
スレッドセーフ性	なし	なし(`ConcurrentDictionary`推奨)
キー・値の型指定	なし	あり
使用推奨度(新規開発)	低い	高い
互換性・レガシー対応	あり	なし
nullキーの扱い	可能	不可

この表を参考にすると、基本的には新しいコードではDictionary<TKey, TValue>を使うのがベストです。

Hashtableはレガシーコードの保守や、型安全性を気にしない一時的な用途に限定して使うとよいでしょう。

データ構造と内部実装の比較

ハッシュ関数の違い

HashtableとDictionary<TKey, TValue>はどちらもハッシュテーブルをベースにしていますが、内部で使われるハッシュ関数やハッシュコードの扱いに違いがあります。

ハッシュ関数はキーからハッシュコードを生成し、データの格納位置を決定する重要な役割を持っています。

Hashtableは、キーのGetHashCode()メソッドを利用してハッシュコードを取得しますが、内部でのハッシュコードの加工や分散処理は比較的シンプルです。

これに対して、Dictionary<TKey, TValue>はより高度なハッシュコードの分散アルゴリズムを採用しており、衝突を減らし高速なアクセスを実現しています。

.NET Framework 世代別の仕様変遷

.NET Frameworkのバージョンによって、ハッシュ関数の実装や衝突回避の方法に変化があります。

.NET Framework 1.0/1.1

Hashtableは単純なハッシュコードを使い、衝突が多く発生しやすい設計でした。

.NET Framework 2.0以降

Dictionary<TKey, TValue>が導入され、より効率的なハッシュ分散アルゴリズムが採用されました。

.NET Core / .NET 5以降

ハッシュコードのランダム化(ハッシュシードの導入)により、ハッシュ衝突攻撃に対する耐性が強化されています。

Dictionaryはこの仕組みを活用しつつ、パフォーマンスを維持しています。

Hashtableの更新

Hashtableも.NET Core以降で一部最適化されていますが、基本的な設計は変わっていません。

このように、Dictionary<TKey, TValue>は新しいランタイムでの最適化が積極的に行われており、より安全かつ高速に動作します。

エントリ管理方式

HashtableとDictionary<TKey, TValue>は、内部でエントリ(キーと値のペア)をどのように管理しているかに違いがあります。

Hashtable

内部的には配列でバケットを管理し、各バケットにエントリのリスト(チェイン)を保持します。

衝突が起きた場合は、同じバケットに複数のエントリが連結リストの形で格納されます。

このため、衝突が多いとリストの走査が増え、パフォーマンスが低下しやすいです。

Dictionary<TKey, TValue>

バケット配列とエントリ配列を別々に管理し、エントリ配列は構造体の配列で格納されます。

衝突が起きた場合は、エントリのnextフィールドで次のエントリのインデックスを指し示す形でチェインを実装しています。

これにより、メモリの局所性が高まり、GCの負担も軽減されます。

また、Dictionaryのエントリは構造体であるため、参照型のHashtableよりもメモリ効率が良く、アクセス速度も向上します。

バケットとロードファクタ

バケットとは、ハッシュテーブル内でハッシュコードに基づいてデータを格納するためのスロットのことです。

ロードファクタは、バケットの使用率を示す指標で、リサイズのタイミングを決める重要なパラメータです。

Hashtableのバケットとロードファクタ

Hashtableは初期容量とロードファクタを指定できます。

ロードファクタはデフォルトで0.72程度に設定されており、バケットの72%が埋まると自動的にリサイズが発生します。

リサイズ時にはバケット数が増え、再ハッシュが行われます。

リサイズはコストが高いため、初期容量を適切に設定することがパフォーマンス向上に繋がります。

Dictionary<TKey, TValue>のバケットとロードファクタ

Dictionaryも同様にバケット配列を持ち、ロードファクタは約0.75に設定されています。

バケットの75%が埋まるとリサイズが発生し、容量が倍増します。

Dictionaryはリサイズ時にエントリ配列も再配置され、効率的に再ハッシュが行われます。

項目	Hashtable	Dictionary<TKey, TValue>
バケット管理	配列＋連結リスト	バケット配列＋エントリ配列(構造体)
ロードファクタ	約0.72	約0.75
リサイズのタイミング	バケットの72%使用時	バケットの75%使用時
リサイズ時の処理	バケット数増加＋再ハッシュ	バケット数倍増＋エントリ再配置

ロードファクタの設定はパフォーマンスとメモリ使用量のバランスに影響します。

高すぎると衝突が増え、低すぎるとメモリが無駄になります。

Dictionaryはこのバランスを最適化しているため、一般的に高速で安定した動作が期待できます。

型安全性とジェネリクス

コンパイル時の型チェック

Hashtableは非ジェネリックコレクションであり、キーと値はすべてobject型として扱われます。

そのため、格納時や取得時に明示的な型変換が必要です。

例えば、値を取り出す際にキャストを行わなければならず、誤った型にキャストすると実行時にInvalidCastExceptionが発生します。

一方、Dictionary<TKey, TValue>はジェネリックコレクションで、キーと値の型をコンパイル時に指定します。

これにより、コンパイラが型の整合性をチェックし、型の不一致によるエラーを事前に防げます。

例えば、Dictionary<int, string>に文字列以外の値を追加しようとすると、コンパイルエラーになります。

この違いにより、Dictionary<TKey, TValue>は型安全性が高く、バグの発生を減らせるメリットがあります。

ボクシング／アンボクシングによる影響

Hashtableはobject型でデータを扱うため、値型structを格納するときにボクシングが発生します。

ボクシングとは、値型をobject型に変換する処理で、ヒープにオブジェクトを生成するためパフォーマンスに影響します。

逆に、取り出す際にはアンボクシングが必要で、これもコストがかかります。

Dictionary<TKey, TValue>はジェネリックで型が固定されているため、値型を格納してもボクシングは発生しません。

これにより、値型の格納・取得が高速に行えます。

値型を格納するケース

例えば、int型の値を格納する場合を考えます。

Hashtableでは、intがobjectにボクシングされて格納されます。

取り出す際にはアンボクシングが必要で、これがパフォーマンスの低下を招きます。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable["number"] = 123; // intがボクシングされる
        int value = (int)hashtable["number"]; // アンボクシング
        Console.WriteLine(value);
    }
}

一方、Dictionary<int, string>のように値型をキーや値に使う場合、ボクシングは発生しません。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<int, string> dictionary = new Dictionary<int, string>();
        dictionary[1] = "One";
        string value = dictionary[1];
        Console.WriteLine(value);
    }
}

One

このように、値型を多用する場合はDictionary<TKey, TValue>のほうがパフォーマンス面で有利です。

参照型を格納するケース

参照型(クラスなど)を格納する場合、HashtableでもDictionary<TKey, TValue>でもボクシングは発生しません。

ただし、Hashtableはキーや値の型がobjectであるため、取り出す際にキャストが必要です。

誤った型にキャストすると実行時エラーになるリスクがあります。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable["key"] = "Hello";
        string value = (string)hashtable["key"]; // キャストが必要
        Console.WriteLine(value);
    }
}

Hello

Dictionary<string, string>の場合は、型が明確なのでキャスト不要で安全に使えます。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, string> dictionary = new Dictionary<string, string>();
        dictionary["key"] = "Hello";
        string value = dictionary["key"]; // キャスト不要
        Console.WriteLine(value);
    }
}

Hello

このように、参照型でもDictionary<TKey, TValue>は型安全性が高く、コードの可読性や保守性が向上します。

パフォーマンス比較

挿入・検索・削除の時間計算量

HashtableとDictionary<TKey, TValue>はどちらもハッシュテーブルを基盤としているため、基本的な操作の時間計算量は平均的にO(1)(定数時間)です。

つまり、要素数が増えても挿入・検索・削除の処理時間はほぼ一定であることが期待されます。

ただし、実際のパフォーマンスには内部実装の違いやハッシュ衝突の頻度が影響します。

挿入

両者ともハッシュコードを計算し、適切なバケットに格納します。

Dictionaryは構造体のエントリ配列を使い、メモリの局所性が高いため高速です。

Hashtableは参照型のリストを使うため、衝突時のリスト走査が増えると遅くなりやすいです。

検索

キーのハッシュコードを使ってバケットを特定し、該当エントリを探します。

Dictionaryは高速なインデックスアクセスが可能で、衝突が少ない設計のため高速です。

Hashtableは衝突時にリストを走査するため、衝突が多いと遅くなります。

削除

削除も検索と同様にバケットを特定し、該当エントリを削除します。

Dictionaryはエントリ配列の管理が効率的で高速です。

Hashtableはリストのノード削除処理が必要で、やや遅くなる傾向があります。

メモリ使用量の傾向

Hashtableはエントリを参照型のオブジェクトとして管理するため、メモリの断片化が起きやすく、GC(ガベージコレクション)の負担が増えることがあります。

また、ボクシングが発生する場合はヒープに余分なオブジェクトが生成されます。

一方、Dictionary<TKey, TValue>はエントリを構造体配列で管理し、値型のボクシングを回避できるため、メモリ効率が良いです。

メモリの連続領域にデータが格納されるため、キャッシュ効率も高くなります。

ただし、Dictionaryはリサイズ時に配列の再割り当てが発生し、一時的にメモリ使用量が増加することがあります。

ベンチマーク設計ポイント

パフォーマンス比較のベンチマークを設計する際は、以下のポイントを考慮すると実際の利用シーンに近い評価が可能です。

データサイズ別の測定項目

小規模データ(数十〜数百件)

小規模では内部処理のオーバーヘッドが目立ちやすいため、初期容量設定やメモリ割り当ての影響を評価します。

中規模データ(数千〜数万件)

実用的な規模での挿入・検索・削除の速度を測定し、リサイズの影響も確認します。

大規模データ(数十万件以上)

大量データでのスケーラビリティやGC負荷、メモリ使用量の変化を評価します。

ランダムアクセスとシーケンシャルアクセス

ランダムアクセス

キーをランダムに生成し、挿入・検索・削除を行うことで、ハッシュ関数の分散性能や衝突処理の効率を評価します。

シーケンシャルアクセス

連続したキーを使い、アクセスパターンが偏る場合のパフォーマンスを測定します。

特にDictionaryのバケット分布やリサイズ挙動に影響します。

これらの条件を組み合わせてベンチマークを行うことで、HashtableとDictionary<TKey, TValue>の実際のパフォーマンス差を明確に把握できます。

例外と戻り値の挙動

存在しないキー参照時

HashtableとDictionary<TKey, TValue>で存在しないキーを参照した場合の挙動は異なります。

Hashtable

存在しないキーでアクセスすると、戻り値はnullになります。

例外は発生しません。

そのため、キーが存在しないかどうかを判定する際は、戻り値がnullかどうかをチェックする必要があります。

ただし、値としてnullが格納されている場合もあるため、単純にnullチェックだけでは判別できないことがあります。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable["key1"] = "value1";
        // 存在しないキーを参照
        object value = hashtable["key2"];
        if (value == null)
        {
            Console.WriteLine("キーが存在しません");
        }
        else
        {
            Console.WriteLine(value);
        }
    }
}

キーが存在しません

Dictionary<TKey, TValue>

存在しないキーでアクセスすると、KeyNotFoundExceptionがスローされます。

例外処理を行うか、TryGetValueメソッドを使って安全に値を取得する方法が推奨されます。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, string> dictionary = new Dictionary<string, string>();
        dictionary["key1"] = "value1";
        try
        {
            string value = dictionary["key2"]; // 存在しないキー
            Console.WriteLine(value);
        }
        catch (KeyNotFoundException)
        {
            Console.WriteLine("キーが存在しません");
        }
    }
}

キーが存在しません

TryGetValueを使うと例外を避けて安全に値を取得できます。

if (dictionary.TryGetValue("key2", out string value))
{
    Console.WriteLine(value);
}
else
{
    Console.WriteLine("キーが存在しません");
}

重複キー追加時

Hashtable

Addメソッドで既に存在するキーを追加しようとすると、ArgumentExceptionがスローされます。

ただし、インデクサー[]を使って値を設定すると、既存のキーの値が上書きされます。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable.Add("key1", "value1");
        try
        {
            hashtable.Add("key1", "value2"); // 例外発生
        }
        catch (ArgumentException)
        {
            Console.WriteLine("重複したキーの追加はできません");
        }
        // インデクサーで上書き可能
        hashtable["key1"] = "value2";
        Console.WriteLine(hashtable["key1"]);
    }
}

重複したキーの追加はできません
value2

Dictionary<TKey, TValue>

Addメソッドで重複キーを追加すると、ArgumentExceptionがスローされます。

インデクサーを使うと既存の値が上書きされます。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, string> dictionary = new Dictionary<string, string>();
        dictionary.Add("key1", "value1");
        try
        {
            dictionary.Add("key1", "value2"); // 例外発生
        }
        catch (ArgumentException)
        {
            Console.WriteLine("重複したキーの追加はできません");
        }
        // インデクサーで上書き可能
        dictionary["key1"] = "value2";
        Console.WriteLine(dictionary["key1"]);
    }
}

重複したキーの追加はできません
value2

null キーと null 値の扱い

Hashtable

nullキーの使用は可能です。

nullをキーにして値を格納できます。

また、値としてもnullを格納できます。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable[null] = "null key value";
        hashtable["key1"] = null;
        Console.WriteLine(hashtable[null]);   // nullキーの値
        Console.WriteLine(hashtable["key1"]); // null値
    }
}

null key value

Dictionary<TKey, TValue>

nullキーは許可されていません。

nullをキーにするとArgumentNullExceptionがスローされます。

ただし、値としてはnullを格納できます(値の型が参照型の場合)。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, string> dictionary = new Dictionary<string, string>();
        try
        {
            dictionary.Add(null, "null key"); // 例外発生
        }
        catch (ArgumentNullException)
        {
            Console.WriteLine("nullキーは許可されていません");
        }
        dictionary["key1"] = null; // null値は許可
        Console.WriteLine(dictionary["key1"] == null ? "null値です" : dictionary["key1"]);
    }
}

nullキーは許可されていません
null値です

このように、Hashtableはnullキーを許容しますが、Dictionary<TKey, TValue>は許容しません。

値のnullはどちらも扱えますが、キーのnullを使う場合はHashtableを選ぶ必要があります。

スレッドセーフ性

単一スレッド前提の注意点

HashtableもDictionary<TKey, TValue>も、基本的には単一スレッドでの使用を前提としています。

複数のスレッドから同時に読み書きが行われる場合、内部状態が不整合になるリスクがあります。

例えば、同時に要素を追加・削除すると、データ破損や例外が発生する可能性があります。

単一スレッド環境であれば、これらのコレクションは問題なく動作しますが、マルチスレッド環境で使う場合は注意が必要です。

特に、読み取りと書き込みが同時に発生するケースでは、適切な同期処理を行わないと予期しない動作を招きます。

ロック戦略の比較

マルチスレッド環境でHashtableやDictionary<TKey, TValue>を安全に使うには、明示的にロックをかける方法が一般的です。

Hashtableの同期機能

HashtableにはSynchronizedメソッドがあり、これを使うとスレッドセーフなラッパーを取得できます。

内部的にすべての操作にロックをかけるため、簡単にスレッドセーフ化できますが、ロックの粒度が粗いためパフォーマンスに影響が出やすいです。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = Hashtable.Synchronized(new Hashtable());
        // 複数スレッドから安全にアクセス可能
        hashtable["key"] = "value";
        Console.WriteLine(hashtable["key"]);
    }
}

value

valueDictionary<TKey, TValue>のロック

Dictionaryにはスレッドセーフなラッパーはありません。

マルチスレッドで使う場合は、lock文などで明示的に同期処理を行う必要があります。

using System;
using System.Collections.Generic;
class Program
{
    static readonly object syncLock = new object();
    static Dictionary<string, string> dictionary = new Dictionary<string, string>();
    static void Main()
    {
        lock (syncLock)
        {
            dictionary["key"] = "value";
        }
        lock (syncLock)
        {
            Console.WriteLine(dictionary["key"]);
        }
    }
}

value

この方法は柔軟ですが、ロックの範囲を適切に管理しないとデッドロックやパフォーマンス低下の原因になります。

ConcurrentDictionary を絡めた代替案

.NET Framework 4.0以降では、マルチスレッド環境での辞書操作に特化したConcurrentDictionary<TKey, TValue>が提供されています。

これは内部で細かいロックやロックフリーのアルゴリズムを使い、高いスレッドセーフ性とパフォーマンスを両立しています。

特徴
- 複数スレッドからの同時読み書きを安全に処理
- ロックの粒度が細かく、スケーラブルな設計
- TryAddやTryRemoveなどのスレッドセーフなメソッドを提供
使い方の例

using System;
using System.Collections.Concurrent;
class Program
{
    static void Main()
    {
        ConcurrentDictionary<string, string> concurrentDict = new ConcurrentDictionary<string, string>();
        // スレッドセーフに追加
        bool added = concurrentDict.TryAdd("key", "value");
        Console.WriteLine($"追加成功: {added}");
        // スレッドセーフに取得
        if (concurrentDict.TryGetValue("key", out string value))
        {
            Console.WriteLine($"値: {value}");
        }
    }
}

追加成功: True
値: value

ConcurrentDictionaryは、HashtableやDictionary<TKey, TValue>のスレッドセーフな代替として推奨されます。

特に高頻度の読み書きが発生するマルチスレッド環境では、明示的なロック管理の手間を減らしつつ安全に使えます。

容量管理とリサイズ

初期容量の決定指針

HashtableやDictionary<TKey, TValue>は内部でバケット配列を使ってデータを管理しています。

初期容量はこのバケット数の初期値を指し、適切に設定することでパフォーマンスの最適化が可能です。

容量が小さすぎる場合

要素数が初期容量を超えるとリサイズが頻繁に発生し、再ハッシュ処理が繰り返されてパフォーマンスが低下します。

容量が大きすぎる場合

メモリを無駄に消費し、キャッシュ効率が悪くなる可能性があります。

初期容量は、予想される最大要素数に対して少し余裕を持たせた値を設定するのが一般的です。

例えば、1000件のデータを格納する場合は、初期容量を1000以上に設定するとリサイズ回数を減らせます。

Dictionary<TKey, TValue>のコンストラクタでは初期容量を指定でき、Hashtableも同様に初期容量を指定可能です。

自動リサイズ発生タイミング

両コレクションは、内部のバケット配列が一定の使用率(ロードファクタ)を超えると自動的にリサイズを行います。

Hashtable

デフォルトのロードファクタは約0.72です。

バケットの72%が埋まるとリサイズが発生し、バケット数が増加します。

Dictionary<TKey, TValue>

ロードファクタは約0.75で、75%を超えるとリサイズが行われます。

リサイズ時にはバケット数が倍増し、すべてのエントリが再ハッシュされます。

リサイズは内部配列の再割り当てと再ハッシュを伴うため、処理コストが高いです。

大量のデータを一度に追加する場合は、初期容量を適切に設定してリサイズ回数を減らすことが重要です。

パフォーマンスへの副作用

リサイズはパフォーマンスに以下のような影響を与えます。

処理の一時的な遅延

リサイズ時には全エントリの再ハッシュと配列コピーが発生し、その間は処理が遅くなります。

大量のデータを追加する際に頻繁にリサイズが起こると、全体の処理時間が大幅に増加します。

メモリ使用量の増加

リサイズ時には新しい大きな配列が確保されるため、一時的にメモリ使用量が増えます。

特に大規模データの場合は注意が必要です。

GC(ガベージコレクション)への影響

大きな配列の割り当てと解放が頻繁に起こると、GCの負荷が増加し、アプリケーションの応答性に影響を与えることがあります。

これらの副作用を抑えるために、初期容量を適切に設定し、リサイズの発生を最小限に抑えることが推奨されます。

また、データの追加が大量に予想される場合は、あらかじめ十分な容量を確保してから操作を行うとよいでしょう。

イテレーションと列挙子

foreach ループの動作差異

HashtableとDictionary<TKey, TValue>はどちらもIEnumerableインターフェースを実装しており、foreachループで要素を列挙できますが、列挙時の挙動や返される要素の型に違いがあります。

Hashtable

Hashtableのforeachループでは、DictionaryEntry型のオブジェクトが返されます。

DictionaryEntryはKeyとValueのプロパティを持つ構造体で、キーと値のペアを表します。

using System;
using System.Collections;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable["apple"] = 100;
        hashtable["banana"] = 200;
        foreach (DictionaryEntry entry in hashtable)
        {
            Console.WriteLine($"Key: {entry.Key}, Value: {entry.Value}");
        }
    }
}

Key: apple, Value: 100
Key: banana, Value: 200

Dictionary<TKey, TValue>

Dictionaryのforeachループでは、KeyValuePair<TKey, TValue>型のオブジェクトが返されます。

こちらもKeyとValueのプロパティを持ちますが、ジェネリック型であるため型安全にアクセスできます。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, int> dictionary = new Dictionary<string, int>();
        dictionary["apple"] = 100;
        dictionary["banana"] = 200;
        foreach (KeyValuePair<string, int> kvp in dictionary)
        {
            Console.WriteLine($"Key: {kvp.Key}, Value: {kvp.Value}");
        }
    }
}

Key: apple, Value: 100
Key: banana, Value: 200

このように、Hashtableは非ジェネリックのDictionaryEntryを返すため、キーや値の型を明示的にキャストする必要がある場合があります。

一方、Dictionaryはジェネリックで型が保証されているため、キャスト不要で安全に扱えます。

変更中のコレクション列挙

HashtableとDictionary<TKey, TValue>の両方とも、列挙中にコレクションを変更するとInvalidOperationExceptionがスローされます。

これは、列挙の整合性を保つための仕組みです。

例えば、foreachループの途中で要素を追加・削除すると例外が発生します。

using System;
using System.Collections.Generic;
class Program
{
    static void Main()
    {
        Dictionary<string, int> dictionary = new Dictionary<string, int>();
        dictionary["apple"] = 100;
        dictionary["banana"] = 200;
        try
        {
            foreach (var kvp in dictionary)
            {
                if (kvp.Key == "apple")
                {
                    dictionary.Remove("banana"); // 例外発生
                }
            }
        }
        catch (InvalidOperationException ex)
        {
            Console.WriteLine($"例外発生: {ex.Message}");
        }
    }
}

例外発生: コレクションが変更されたため、列挙操作は無効になりました。

このため、列挙中にコレクションを変更したい場合は、以下のような対策が必要です。

変更対象の要素を別のリストに一時的に保存し、列挙終了後にまとめて変更します
forループやインデックスを使って安全に操作する(ただし、Dictionaryはインデックスアクセスができないため注意)
スレッドセーフなコレクションやコピーを使います

拡張メソッド利用時の注意点

LINQなどの拡張メソッドを使ってHashtableやDictionary<TKey, TValue>を操作する場合、いくつか注意点があります。

Hashtableは非ジェネリックのため、LINQの型推論が効きにくい

HashtableはIEnumerableを実装していますが、要素がDictionaryEntry型であるため、LINQのクエリやメソッドチェーンで型を明示的に指定しないとコンパイルエラーやランタイムエラーになることがあります。

using System;
using System.Collections;
using System.Linq;
class Program
{
    static void Main()
    {
        Hashtable hashtable = new Hashtable();
        hashtable["apple"] = 100;
        hashtable["banana"] = 200;
        // 明示的にキャストが必要
        var keys = hashtable.Cast<DictionaryEntry>().Select(entry => entry.Key);
        foreach (var key in keys)
        {
            Console.WriteLine(key);
        }
    }
}

apple
banana

Dictionary<TKey, TValue>はジェネリック対応でLINQが自然に使える

DictionaryはIEnumerable<KeyValuePair<TKey, TValue>>を実装しているため、LINQの拡張メソッドが型安全に使えます。

using System;
using System.Collections.Generic;
using System.Linq;
class Program
{
    static void Main()
    {
        Dictionary<string, int> dictionary = new Dictionary<string, int>();
        dictionary["apple"] = 100;
        dictionary["banana"] = 200;
        var keys = dictionary.Select(kvp => kvp.Key);
        foreach (var key in keys)
        {
            Console.WriteLine(key);
        }
    }
}

apple
banana

列挙中の変更に注意

LINQのクエリは遅延実行されるため、列挙時にコレクションが変更されると例外が発生することがあります。

必要に応じてToList()やToArray()で即時実行し、コピーを作成してから操作すると安全です。

これらの点を踏まえ、拡張メソッドを使う際はコレクションの型や列挙のタイミングに注意してください。

キーのハッシュコード実装

カスタム型をキーにする場合

HashtableやDictionary<TKey, TValue>でカスタムクラスや構造体をキーに使う場合、キーのハッシュコードの実装が非常に重要です。

ハッシュコードはGetHashCode()メソッドで返され、ハッシュテーブルのバケットを決定するために使われます。

カスタム型をキーにする際は、以下のポイントを押さえてGetHashCode()とEquals()メソッドを適切にオーバーライドする必要があります。

GetHashCode()の実装

オブジェクトの状態を元に一意性を表す整数値を返します。

異なるオブジェクトが同じハッシュコードを返すことは許容されますが、できるだけ衝突を避けるために、キーの重要なフィールドを組み合わせて計算します。

Equals()の実装

同じキーとみなす条件を定義します。

ハッシュコードが同じでもEquals()がfalseなら別のキーとして扱われます。

例：カスタムクラスの実装例

using System;
using System.Collections.Generic;
class Person
{
    public string FirstName { get; }
    public string LastName { get; }
    public Person(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }
    public override bool Equals(object obj)
    {
        if (obj is Person other)
        {
            return FirstName == other.FirstName && LastName == other.LastName;
        }
        return false;
    }
    public override int GetHashCode()
    {
        // 文字列のハッシュコードを組み合わせる
        int hashFirst = FirstName?.GetHashCode() ?? 0;
        int hashLast = LastName?.GetHashCode() ?? 0;
        return hashFirst ^ hashLast; // XORで組み合わせ
    }
}
class Program
{
    static void Main()
    {
        var dict = new Dictionary<Person, string>();
        var p1 = new Person("John", "Doe");
        var p2 = new Person("John", "Doe");
        dict[p1] = "Engineer";
        Console.WriteLine(dict.ContainsKey(p2)); // True
        Console.WriteLine(dict[p2]);             // Engineer
    }
}

True
Engineer

この例では、p1とp2は異なるインスタンスですが、EqualsとGetHashCodeを正しく実装しているため、同じキーとして扱われます。

衝突回避のベストプラクティス

ハッシュコードの衝突はパフォーマンス低下の原因となるため、できるだけ衝突を減らす工夫が必要です。

複数のフィールドを組み合わせる

キーの重要なフィールドを複数使い、ハッシュコードを計算します。

単一フィールドだけでなく、複数の値を組み合わせることで衝突を減らせます。

適切なハッシュ関数の利用

単純なXORだけでなく、ビットシフトや乗算を使ったハッシュコード生成が推奨されます。

例えば、.NETのHashCode.Combineメソッドを使うと簡単に良質なハッシュコードが作れます。

public override int GetHashCode()
{
    return HashCode.Combine(FirstName, LastName);
}

不変なキーを使う

キーの状態が変わるとハッシュコードも変わり、コレクションの整合性が崩れます。

キーは不変(イミュータブル)に設計することが重要です。

ハッシュコードのキャッシュ

計算コストが高い場合は、ハッシュコードを一度計算してキャッシュする方法もあります。

ただし、状態が変わらないことが前提です。

不変性とオブジェクト寿命

キーとして使うオブジェクトは不変であることが望ましいです。

理由は以下の通りです。

ハッシュコードの一貫性

キーの状態が変わるとGetHashCode()の結果が変わり、ハッシュテーブル内の位置が不正確になります。

これにより、要素が見つからなくなったり、重複が発生したりします。

Equals()の一貫性

状態が変わるとEquals()の結果も変わり、同じキーとして扱われなくなります。

オブジェクト寿命の管理

キーオブジェクトが長期間コレクションに保持されるため、不要になったキーは適切に削除しないとメモリリークの原因になります。

特に大きなオブジェクトをキーにする場合は注意が必要です。

イミュータブルな設計例

public sealed class ImmutablePerson
{
    public string FirstName { get; }
    public string LastName { get; }
    public ImmutablePerson(string firstName, string lastName)
    {
        FirstName = firstName;
        LastName = lastName;
    }
    // Equals と GetHashCode は省略(前述の例と同様)
}

このように、キーは変更されない設計にし、ハッシュコードと等価性が常に一定であることを保証することが、HashtableやDictionary<TKey, TValue>を正しく使う上で非常に重要です。

セキュリティ観点

ハッシュ衝突攻撃への耐性

ハッシュテーブルを利用するHashtableやDictionary<TKey, TValue>は、キーのハッシュコードを使ってデータの格納位置を決定します。

この仕組みは高速なアクセスを可能にしますが、悪意のある攻撃者が意図的に同じハッシュコードを持つキーを大量に生成すると、ハッシュ衝突が多発し、パフォーマンスが著しく低下する「ハッシュ衝突攻撃(Hash Collision Attack)」のリスクがあります。

攻撃の仕組み

攻撃者が同じハッシュコードを持つ大量のキーを送信すると、ハッシュテーブルのバケットに衝突が集中し、内部でのリストやチェインの走査が増加します。

これにより、通常はO(1)の操作が最悪O(n)に近くなり、サービス拒否(DoS)攻撃の一種として悪用されることがあります。

Hashtableの耐性

古いHashtableはハッシュコードのランダム化がなく、攻撃に対して脆弱でした。

特に.NET Frameworkの初期バージョンではこの問題が顕著でした。

Dictionary<TKey, TValue>の耐性

.NET Coreや.NET 5以降のDictionaryは、ハッシュコードのシード値をランタイム起動時にランダムに設定し、ハッシュコードの分布をランダム化する仕組みを導入しています。

これにより、攻撃者が予測可能なハッシュコードを生成しにくくなり、ハッシュ衝突攻撃への耐性が大幅に向上しています。

開発者ができる対策
- カスタムのGetHashCode()実装では、単純なハッシュコード生成を避け、十分に分散性の高いアルゴリズムを使います
- 外部からの入力をキーに使う場合は、入力の検証や制限を行い、不正な大量リクエストを防ぐ
- 最新の.NETランタイムを利用し、ハッシュコードのランダム化機能を活用します

シリアライズ／デシリアライズ時のリスク

HashtableやDictionary<TKey, TValue>はシリアライズ(オブジェクトのバイト列化)とデシリアライズ(復元)に対応していますが、この過程でセキュリティリスクが発生することがあります。

デシリアライズの脆弱性

攻撃者が細工したシリアライズデータを送信し、デシリアライズ処理を行うと、任意のコード実行やサービス停止を引き起こす可能性があります。

特に、信頼できないデータをデシリアライズする場合は注意が必要です。

Hashtableのリスク

Hashtableは古いシリアライズ形式を使うことが多く、デシリアライズ時に型の不整合や予期しないオブジェクト生成が起こることがあります。

これにより、セキュリティホールとなる場合があります。

Dictionary<TKey, TValue>のリスク

ジェネリック型であるDictionaryも同様にシリアライズ可能ですが、型安全性が高いため、型の不整合による問題は比較的少ないです。

ただし、やはり信頼できないデータのデシリアライズは危険です。

対策方法
- 信頼できるソースからのデータのみをデシリアライズします
- 可能な限り、JSONやXMLなどの安全なシリアライズ形式を使い、専用のシリアライザ(例：System.Text.JsonやNewtonsoft.Json)を利用します
- デシリアライズ時に型制限や検証を行い、不正なデータを排除します
- .NETのセキュリティアップデートを適用し、既知の脆弱性を解消します

これらのポイントを踏まえ、HashtableやDictionary<TKey, TValue>を使う際は、特に外部からの入力をキーにする場合やシリアライズ処理を行う場合に、セキュリティリスクを十分に考慮することが重要です。

互換性と移行戦略

レガシーコードでの Hashtable 残存理由

多くの既存のC#プロジェクトやライブラリでは、Hashtableが長年使われてきました。

Hashtableが残存している主な理由は以下の通りです。

歴史的経緯

Hashtableは.NET Frameworkの初期から存在し、ジェネリックが導入される前の標準的なキー・値ペアコレクションでした。

古いコードベースでは大量に使われており、互換性維持のためにそのまま残されています。

互換性の問題

Hashtableは非ジェネリックでobject型を扱うため、既存のコードやAPIと密接に結びついています。

Dictionary<TKey, TValue>に置き換えると型の不一致やキャストの問題が発生しやすく、単純な置換が難しい場合があります。

コストとリスク

大規模なシステムでHashtableをDictionaryに置き換えるには、テストや修正が膨大になり、バグ発生リスクも高まります。

安定稼働を優先し、急激な変更を避けるためにHashtableを使い続けるケースがあります。

特定の機能依存

Hashtableのnullキー許容やSynchronizedメソッドなど、Dictionaryにはない機能に依存している場合もあります。

段階的な Dictionary 置換手順

レガシーコードのHashtableをDictionary<TKey, TValue>に段階的に置換する際は、以下の手順を踏むと安全かつ効率的です。

影響範囲の調査

Hashtableが使われている箇所を洗い出し、キー・値の型や使用パターンを把握します。

特にnullキーやnull値の扱い、スレッドセーフ性の要件を確認します。

型の特定と設計

置換先のDictionaryで使うキーと値の型を明確に決めます。

可能な限り具体的な型を指定し、型安全性を高めます。

テストコードの整備

既存の動作を保証するために、ユニットテストや統合テストを充実させます。

置換作業中のリグレッションを防ぐために重要です。

部分的な置換

影響が小さいモジュールや新規開発部分からDictionaryを導入し、動作確認を行います。

HashtableとDictionaryが混在しても問題ない設計にします。

APIのラッパー作成

既存のHashtableをラップするAPIを作成し、内部でDictionaryを使う方法も有効です。

これにより、呼び出し側のコード変更を最小限に抑えられます。

全体置換と最終検証

残りのHashtableを順次Dictionaryに置換し、テストを繰り返して問題がないことを確認します。

API 互換レイヤの作成ポイント

HashtableからDictionary<TKey, TValue>への移行で、既存コードの互換性を保つためにAPI互換レイヤを作成することがあります。

以下のポイントを押さえるとスムーズに移行できます。

インターフェースの統一

Hashtableの主要メソッド(Add、Remove、Contains、インデクサーなど)を模倣したラッパークラスを作成し、内部でDictionaryを操作します。

型安全性の確保

ラッパーのジェネリック化を検討し、呼び出し側に型安全なAPIを提供します。

必要に応じてキャスト処理を内部に隠蔽します。

nullキーの扱い

Hashtableはnullキーを許容しますが、Dictionaryは許容しません。

ラッパーでnullキーを特別扱いするか、nullキーを使わない設計に変更する必要があります。

スレッドセーフ性の対応

Hashtable.Synchronizedのようなスレッドセーフ機能が必要な場合は、ラッパー内でロック処理を実装するか、ConcurrentDictionaryへの切り替えを検討します。

例外処理の整合性

HashtableとDictionaryで例外の種類やタイミングが異なる場合があるため、ラッパーで例外を適切に変換・処理し、既存コードの期待に沿うようにします。

パフォーマンスの考慮

ラッパーによるオーバーヘッドを最小限に抑え、パフォーマンス劣化を防ぐ設計を心がけます。

このように、API互換レイヤを活用することで、既存のHashtable依存コードを大幅に書き換えずに、内部実装をDictionaryに移行できるため、リスクを抑えつつモダナイズが可能です。

よくある落とし穴

パフォーマンスチューニングの勘違い

HashtableやDictionary<TKey, TValue>のパフォーマンスを向上させようとして、誤ったチューニングを行うケースがよくあります。

代表的な勘違いは以下の通りです。

初期容量を過剰に大きく設定する

初期容量を必要以上に大きくすると、メモリ使用量が無駄に増え、キャッシュ効率が悪化します。

結果として、パフォーマンスが逆に低下することがあります。

適切な初期容量は、予想される要素数に少し余裕を持たせた程度に設定するのがベストです。

頻繁なリサイズを避けるために極端に大きな容量を設定する

リサイズは確かにコストが高いですが、極端に大きな容量を確保するとメモリ圧迫やGC負荷が増加します。

バランスを考慮し、必要に応じて段階的に容量を増やす設計が望ましいです。

ボクシング／アンボクシングの影響を軽視する

Hashtableは値型を格納するとボクシングが発生し、パフォーマンスに悪影響を与えます。

これを無視してHashtableを使い続けると、思わぬ速度低下を招きます。

値型を多用する場合はDictionary<TKey, TValue>を使うべきです。

スレッドセーフ性の誤認

HashtableのSynchronizedメソッドやlockを使わずにマルチスレッドで使うと、データ破損や例外が発生します。

スレッドセーフ性を確保しないままパフォーマンスを追求するのは危険です。

型変換エラーと例外捕捉漏れ

Hashtableは非ジェネリックでobject型を扱うため、型変換エラーが発生しやすいです。

以下のような問題がよく起こります。

キャストミスによるInvalidCastException

取り出した値を誤った型にキャストすると例外が発生します。

特に複数の型が混在する場合や、コードの変更で型が変わった場合に起こりやすいです。

例外捕捉漏れ

例外が発生する可能性がある操作で適切にtry-catchを使わず、アプリケーションがクラッシュすることがあります。

特に存在しないキーの参照や重複キーの追加時に注意が必要です。

null値とnullキーの混同

Hashtableはnullキーやnull値を許容しますが、これが原因で型変換時に予期しないNullReferenceExceptionが発生することがあります。

nullチェックを怠らないことが重要です。

対策
- 可能な限りDictionary<TKey, TValue>を使い、コンパイル時の型チェックを活用します
- Hashtableを使う場合は、取り出し時に型チェックやas演算子を使い安全にキャストします
- 例外処理を適切に実装し、エラー発生時にログを残すなどの対策を行います

サイズ増加による GC 圧迫

HashtableやDictionary<TKey, TValue>は内部で配列を使っており、サイズが増加するとメモリ使用量が大きくなります。

これがGC(ガベージコレクション)に与える影響は以下の通りです。

大きな配列の割り当てと解放

リサイズ時に新しい大きな配列を確保し、古い配列はGCの対象になります。

頻繁なリサイズや大容量の確保はGC負荷を増大させ、アプリケーションの応答性を低下させます。

メモリ断片化の発生

大きなオブジェクトヒープ(LOH)に配列が割り当てられると、メモリ断片化が起こりやすくなります。

これにより、メモリ効率が悪化し、GCのパフォーマンスが低下します。

長時間生存オブジェクトの増加

大きなコレクションは長期間メモリに残ることが多く、世代0や世代1のGCでは回収されにくい世代2オブジェクトが増え、GCの負荷が高まります。

対策
- 初期容量を適切に設定し、リサイズ回数を減らす
- 不要になったコレクションは早めに破棄し、参照を切ります
- 大量データの処理は分割して行い、一度に大きなコレクションを作らない
- 必要に応じてGC.Collect()を使うが、乱用は避けます

これらの落とし穴を理解し、適切な設計と運用を行うことで、HashtableやDictionary<TKey, TValue>のパフォーマンスと安定性を維持できます。

ユースケース別の採用判断

コンフィグ設定のキー／値管理

アプリケーションの設定情報をキーと値のペアで管理する場合、HashtableとDictionary<TKey, TValue>のどちらを使うかは、主に以下のポイントで判断します。

型安全性の重要度

設定値の型が多様であったり、動的に変わる場合はHashtableの柔軟性が活きます。

ただし、型安全性が求められる場合はDictionary<string, string>やDictionary<string, object>など、明確な型指定ができるDictionaryが望ましいです。

パフォーマンス要件

設定情報は通常、起動時や初期化時に読み込まれ、その後は頻繁に変更されないため、パフォーマンスの差はあまり問題になりません。

したがって、保守性や型安全性を優先してDictionaryを選ぶケースが多いです。

nullキーの扱い

設定キーにnullを使うことは稀ですが、もし必要ならHashtableが対応可能です。

ただし、一般的にはnullキーは避けるべきです。

// Dictionaryを使った設定管理例
var config = new Dictionary<string, string>
{
    ["AppName"] = "MyApp",
    ["MaxUsers"] = "100"
};
if (config.TryGetValue("AppName", out string appName))
{
    Console.WriteLine($"アプリ名: {appName}");
}

リアルタイム処理での選択肢

リアルタイム処理や高頻度のデータアクセスが求められる場面では、コレクションの選択がパフォーマンスに直結します。

Dictionary<TKey, TValue>の優位性

ジェネリックで型安全かつボクシングが発生しないため、値型を多用するリアルタイム処理に適しています。

高速な挿入・検索・削除が可能です。

Hashtableの制約

ボクシング・アンボクシングのオーバーヘッドがあり、パフォーマンスが劣るため、リアルタイム処理には不向きです。

スレッドセーフ性の考慮

リアルタイム処理はマルチスレッドで動作することが多いため、Dictionary単体ではスレッドセーフではありません。

ConcurrentDictionaryの利用や適切なロック機構の導入が必要です。

using System.Collections.Concurrent;
var realtimeData = new ConcurrentDictionary<int, double>();
// 高頻度の更新・参照に対応
realtimeData[1] = 123.45;
if (realtimeData.TryGetValue(1, out double value))
{
    Console.WriteLine($"値: {value}");
}

低レイテンシ API サーバーでの考慮事項

APIサーバーなど、低レイテンシが求められる環境では、コレクションの選択がレスポンス速度に影響します。

高速アクセスと型安全性

Dictionary<TKey, TValue>は高速なアクセス性能と型安全性を兼ね備えており、APIサーバーのキャッシュやセッション管理に適しています。

スレッドセーフな設計

多数の同時リクエストを処理するため、ConcurrentDictionaryの利用が推奨されます。

これによりロック競合を減らし、スケーラブルな性能を実現できます。

メモリ効率とGC負荷の最小化

大量のリクエストをさばく環境では、メモリ使用量やGCの影響も重要です。

DictionaryはHashtableよりメモリ効率が良く、GC負荷を抑えやすいです。

using System.Collections.Concurrent;
public class ApiCache
{
    private ConcurrentDictionary<string, object> cache = new ConcurrentDictionary<string, object>();
    public void Set(string key, object value)
    {
        cache[key] = value;
    }
    public bool TryGet(string key, out object value)
    {
        return cache.TryGetValue(key, out value);
    }
}

このように、低レイテンシAPIサーバーでは、DictionaryやConcurrentDictionaryを活用し、型安全かつスレッドセーフな設計を心がけることが重要です。

代替コレクションとの比較

SortedDictionary と OrderedDictionary

SortedDictionary<TKey, TValue>とOrderedDictionaryは、HashtableやDictionary<TKey, TValue>とは異なる特徴を持つコレクションで、用途に応じて使い分けられます。

SortedDictionary<TKey, TValue>
- 特徴

キーが自動的にソートされるジェネリックコレクションです。

内部的にはバランスの取れた二分探索木(通常は赤黒木)を使っており、キーの順序が常に昇順に保たれます。

用途

順序付きのキーで高速な検索や範囲検索が必要な場合に適しています。

パフォーマンス

挿入・削除・検索は平均O(log n)の時間計算量で、ハッシュテーブルよりは遅いですが、順序が保証されるメリットがあります。

OrderedDictionary
- 特徴

非ジェネリックで、キーと値のペアを挿入順に保持するコレクションです。

System.Collections.Specialized名前空間に属します。

用途

順序を保持しつつ、キーによる高速アクセスも必要な場合に使われます。

パフォーマンス

内部的にはハッシュテーブルとリストの組み合わせで実装されており、挿入順の保持と高速アクセスを両立していますが、ジェネリックではないため型安全性は低いです。

ImmutableDictionary と不変コレクション

ImmutableDictionary<TKey, TValue>
- 特徴

変更不可(イミュータブル)な辞書コレクションで、変更操作は新しい辞書を返します。

スレッドセーフであり、状態の共有や並行処理に適しています。

用途

状態の変更を避けたいシナリオや、並行処理で安全に共有したい場合に有効です。

パフォーマンス

変更時に新しいインスタンスを生成しますが、内部的に構造共有を行うため効率的です。

読み取りは高速です。

不変コレクションのメリット
- スレッドセーフでロック不要
- バグの原因となる状態変更を防止
- 関数型プログラミングスタイルに適合

高速読み取り専用シナリオでの ReadOnlyDictionary

ReadOnlyDictionary<TKey, TValue>
- 特徴

既存のIDictionary<TKey, TValue>をラップし、読み取り専用のインターフェースを提供します。

内部データは変更できませんが、元の辞書が変更されると反映されます。

用途

APIの公開インターフェースで、外部からの書き換えを防ぎたい場合や、読み取り専用として安全にデータを渡したい場合に使います。

パフォーマンス

ラップするだけなのでオーバーヘッドはほとんどなく、高速な読み取りが可能です。

これらの代替コレクションは、用途や要件に応じてHashtableやDictionary<TKey, TValue>と使い分けることで、より適切な設計とパフォーマンスを実現できます。

今後の .NET エコシステム動向

ランタイム最適化の新機能

.NETのランタイムは常に進化を続けており、パフォーマンスやメモリ効率の向上を目的とした最適化機能が次々と導入されています。

特にコレクション関連では以下のような新機能が注目されています。

ハッシュテーブルの高速化

.NET 6以降では、Dictionary<TKey, TValue>の内部実装がさらに最適化され、ハッシュコードの計算やバケット探索の効率が向上しています。

これにより、大量データの挿入や検索がより高速に行えます。

構造体の最適化

ジェネリックコレクションで使われる構造体のボクシングを回避するため、ランタイムレベルでの最適化が進んでいます。

これにより、値型をキーや値に使う場合のパフォーマンスが改善されています。

低レイテンシGC(Garbage Collector)

.NETのGCは低レイテンシ化が進み、特に大規模なコレクションを扱うアプリケーションでのパフォーマンス向上に寄与しています。

これにより、コレクションのリサイズや大量割り当て時の影響が軽減されます。

ランタイムによるハッシュコードのランダム化強化

セキュリティ強化の一環として、ハッシュ衝突攻撃に対する耐性がさらに強化され、ランダムシードの管理やハッシュ関数の改良が行われています。

コレクション API 拡張計画

.NETのコレクションAPIは、開発者のニーズに応えるべく拡張が続けられています。

今後の計画や注目すべき動向は以下の通りです。

新しいジェネリックコレクションの追加

不変コレクションや並列処理向けのコレクションが拡充され、より多様なユースケースに対応できるようになります。

例えば、ImmutableSortedDictionaryの機能強化や、より効率的な並列コレクションの提供が予定されています。

パフォーマンス重視のAPI改善

既存のコレクションに対して、メモリ割り当てを抑えた軽量な操作や、Span<T>やMemory<T>を活用した高速処理を可能にするAPIの追加が進んでいます。

非同期対応のコレクション

非同期プログラミングの普及に伴い、非同期操作に適したコレクションやストリーム処理との連携強化が検討されています。

拡張メソッドの充実

LINQやその他の拡張メソッドがさらに充実し、コレクション操作の表現力と効率が向上します。

特にパフォーマンスを意識したメソッド群の追加が期待されています。

クロスプラットフォーム対応の強化

.NETのクロスプラットフォーム展開に伴い、各プラットフォームで一貫したコレクション動作と最適化が図られています。

これらの動向により、今後の.NET環境では、より高速で安全、かつ柔軟なコレクション操作が可能となり、開発者の生産性とアプリケーションの品質向上に寄与していきます。

まとめ

この記事では、C#のHashtableとDictionary<TKey, TValue>の違いを型安全性、パフォーマンス、例外処理、スレッドセーフ性など多角的に比較しました。

Dictionaryはジェネリックで型安全かつ高速であり、新規開発では推奨されます。

一方、Hashtableはレガシーコードや特定の用途で残存しています。

用途や環境に応じて適切なコレクションを選び、パフォーマンスや安全性を最大化することが重要です。

参考文献