What is the difference between ArrayList and List<T> in C#? Why is ArrayList still in .NET, and what goes wrong when you use it in new code?

1. Same internal design, different element storage

Both types hold a backing array plus a count:

// ArrayList (simplified)
private object?[] _items;
private int _size;
private int _version;

// List<T>
private T[] _items;
private int _size;
private int _version;

Growth is the same (doubling, starting at 4), Add is amortised O(1), Insert/RemoveAt are O(n) shifts. The difference is entirely what lives in the array: references to boxes for value types in ArrayList, versus inline values in List<int>.

2. Generics and code generation

List<T> relies on .NET's reified generics:

• For each value type argument (List<int>, List<decimal>), the JIT generates specialised native code with T known — no boxing, direct comparisons, inlining.
• For reference type arguments, one shared implementation (List<__Canon>) is used, with type information passed via a hidden dictionary for things like casts.

This is unlike Java's type-erased generics, where List<Integer> still boxes. It is why List<T> of value types is dramatically more efficient than ArrayList.

3. Boxing costs in detail

Adding an int to ArrayList:

1. box Int32 allocates a 24-byte object on the heap (header + MethodTable + 4-byte value + padding).
2. The reference is stored in the object[] (with a GC write barrier and a covariance check).

Reading: unbox.any Int32 checks the type and copies the value. For a million elements: a million allocations, a million objects for the GC to mark, and poor cache locality because boxes are scattered across the heap.

4. Enumerators

• ArrayList.GetEnumerator() returns an IEnumerator implemented by a class — one allocation per foreach, plus interface calls for MoveNext and Current, and Current returns object (requiring an unbox).
• List<T>.GetEnumerator() returns List<T>.Enumerator, a struct, so foreach allocates nothing and the JIT can inline the calls.

5. Thread-safety wrappers

ArrayList.Synchronized(list) returns a wrapper that locks on every call — but compound operations (check-then-add, enumerate) still aren't atomic. Generic collections dropped these wrappers; the recommended approach is explicit locking or concurrent collections. Seeing ArrayList.Synchronized in legacy code is a sign of possible race conditions.

6. Other non-generic collections to avoid

Roslyn analysers and code-quality tools (and the Microsoft.CodeAnalysis.BannedApiAnalyzers with a BannedSymbols.txt) can block them in new code.

7. Interop with non-generic interfaces

List<T> implements IList explicitly, so legacy APIs expecting IList accept it. Writes through IList.Add(object) are type-checked at run time and throw ArgumentException for wrong types — safer than ArrayList, which accepts anything.

Try it yourself

1. Benchmark adding and summing 1 million ints with ArrayList vs List<int> using [MemoryDiagnoser].
2. Take a dotnet-gcdump and count System.Int32 objects in each case.
3. Add a string to an ArrayList of numbers and sum it; then try the same with List<decimal>.
4. Pass a List<int> to a method expecting IList and call Add("x") through it.

using System.Collections;

// Legacy: compiles, fails at run time
var legacy = new ArrayList { 10, 20, "thirty" };   // 10 and 20 are boxed
int total = 0;
foreach (object o in legacy)
    total += (int)o;                                  // InvalidCastException on "thirty"

// Modern: the compiler stops the bug
List<int> amounts = [10, 20];
// amounts.Add("thirty");                           // CS1503: cannot convert string to int
int sum = amounts.Sum();                              // no casts, no boxing

// Migrating legacy data
List<int> migrated = legacy.OfType<int>().ToList();   // skips "thirty" silently
List<int> strict   = legacy.Cast<int>().ToList();     // throws, which is usually what you want