Articles

Blogs

MCQ

SQL

Q&A

Tools

Tags

Jobs

News

Community

LogIn

Email

Password

Show Password

Forget Password

I don't have account.Sign Up!

Login

‹ ›

‹ ›

‹ ›

Sponsored -55%

Tarkan Top Brand

Tarkan Portable Folding Laptop Desk with Drawer, Cup & Tablet Holder (Black)

Foldable · Anti-slip strip · 60 × 40 cm · No assembly

★★★★★★★★★★ 4.2 (7,877) 1K+ bought last month

₹899 M.R.P. ₹1,999Save ₹1,100

Buy Now →

Adℹ

✕

What Happens If You Override Equals() but Not GetHashCode() in C#

Shubham Verma

Last Updated : 31 October 2025

39 Views

#hashset

#hashmap

#dictionary

#collections

#c-sharp-collection

Adℹ

When working with collections like HashSet or Dictionary<TKey, TValue>, understanding the relationship between Equals() and GetHashCode() is critical. Many hidden bugs and performance problems in .NET apps happen because these two methods are used incorrectly.

Let’s unpack this in detail step by step.

The Role of Equals() and GetHashCode()

Every object in C# inherits two fundamental methods from System.Object:

• public virtual bool Equals(object obj);
• public virtual int GetHashCode();

They work hand-in-hand to determine object equality and hash identity.

• Equals() defines logical equality — when two objects mean the same thing.

• GetHashCode() provides a hash used for fast lookups in hash-based collections (like HashSet, Dictionary and ConcurrentDictionary).

How Hash-Based Collections Work

Collections like HashSet and Dictionary<TKey, TValue> are hash-based. They use a two-step process for lookup and storage:

Hashing Phase:

• Call GetHashCode() to compute an integer hash.
• This determines which bucket an object belongs to.

Equality Phase:

• Once inside the right bucket, call Equals() to check if the item is actually equal to an existing entry.

Example: HashSet Internals (Simplified)

Imagine a HashSet as multiple buckets (like small lists):

Bucket 0: [ ]
Bucket 1: [ ]
Bucket 2: [Person("Alice")]
Bucket 3: [ ]
Bucket 4: [Person("Bob")]

When you add new Person("Alice"):

• The hash code decides which bucket to use.

• Then Equals() ensures no duplicates exist in that bucket.

If GetHashCode() returns different values for logically equal objects, they end up in different buckets and Equals() never even gets called to compare them.

This is the Problem when Overriding Equals() but Not GetHashCode()

Consider this class:

class Person
{
    public string Name { get; set; }

    public override bool Equals(object obj)
    {
        return obj is Person other && Name == other.Name;
    }

    // ❌ Forgot to override GetHashCode()
}

Let’s test it:

var set = new HashSet<Person>();
set.Add(new Person { Name = "Dev" });
set.Add(new Person { Name = "Dev" });

Console.WriteLine(set.Count);  // Output: 2

Even though both objects are logically equal (Equals() returns true), HashSet stores both, because they have different hash codes.

Why It Happens

By default, GetHashCode() (from object) uses the object's reference in memory. So, two different instances even with identical content, produce different hash codes.

Since the hash codes are different, the objects might end up in different buckets (bucketIndex = hashCode % capacity). In that case, the HashSet won’t even call Equals() to compare them. It only calls Equals() if both objects fall into the same bucket.

The Object Equality Contract

Microsoft’s official guidelines define a clear contract between Equals() and GetHashCode():

If two objects are equal (according to Equals()),
they must return the same value from GetHashCode().

Violating this rule leads to unpredictable behavior in any hash-based collection.

The Rules Summarized

Rule	Description
Reflexive	x.Equals(x) must be true.
Symmetric	x.Equals(y) must equal y.Equals(x).
Transitive	If x.Equals(y) and y.Equals(z), then x.Equals(z) must be true.
Consistency	Repeated calls must return the same result unless the object changes.
Hash Code Contract	If x.Equals(y) is true, then x.GetHashCode() == y.GetHashCode() must be true.

.

Correct Implementation Example

Here’s how to fix it properly:

class Person
{
    public string Name { get; set; }

    public override bool Equals(object obj)
    {
        return obj is Person other && Name == other.Name;
    }

    public override int GetHashCode()
    {
        // Null-safe hash computation
        return Name?.GetHashCode() ?? 0;
    }
}

Now test again:

var set = new HashSet<Person>();

set.Add(new Person { Name = "Dev" });
set.Add(new Person { Name = "Dev" });

Console.WriteLine(set.Count);  // ✅ Output: 1

Now Equals() and GetHashCode() are consistent both objects hash to the same bucket and the duplicate is detected.

Real-World Impact

Here’s what can break if you don’t override both:

Collection	Problem
HashSet	Stores duplicates that should be equal.
Dictionary<TKey, TValue>	Treats equal keys as distinct, causing overwriting or lookup failures.
ConcurrentDictionary<TKey, TValue>	Thread-safe version suffers the same issue.
LINQ	Some LINQ methods (like Distinct()) rely on hash codes and may misbehave.
Contains(), Remove()	Fail to find existing items that are considered “equal.”

Performance Implications

Even if things seem to work, a broken hash implementation can:

• Dramatically increase lookup time (because objects go into wrong buckets)

• Cause memory waste (duplicate entries)

• Lead to unpredictable behavior across different .NET versions or runtime optimizations

• Hash-based collections rely on hash uniformity for performance — mismatched hashes kill that.

How to Implement GetHashCode() Safely

A robust hash code implementation should:

• Use immutable fields (values that don’t change after construction)

• Combine multiple fields using a reliable hash combiner

• Avoid overflow or randomization issues

Example:

class Employee
{
    public int Id { get; set; }
    public string Department { get; set; }

    public override bool Equals(object obj)
    {
        return obj is Employee e && Id == e.Id && Department == e.Department;
    }

    public override int GetHashCode()
    {
        return HashCode.Combine(Id, Department);
    }
}

.NET’s HashCode.Combine() (C# 8+) simplifies safe, high-quality hash generation.

Common Misconceptions

Myth	Reality
"Equals() is enough to define equality."	Not for hash-based collections - you need consistent hashes.
"GetHashCode() must be unique."	No , only consistent. Collisions are okay; inconsistency isn’t.
"You must override Equals() and GetHashCode() together."	Always. They’re inseparable for logical equality.
"Changing hash logic later is safe."	Not for persisted or serialized collections. it may corrupt lookups.

Summary

Concept	Explanation
Equals()	Defines logical equality between objects.
GetHashCode()	Determines hash identity for collections.
If only Equals() is overridden	Hash-based collections misbehave (duplicates, failed lookups).
If both are overridden correctly	Consistent, predictable equality semantics.
Golden Rule	Equal objects must have equal hash codes.

In Short

If you override Equals(), you must override GetHashCode().

Failing to do so may not crash your program, but it will silently break correctness in ways that are hard to debug.

Example Summary in One Line

HashSet won’t even check equality between two objects unless their hash codes match.

Trending Developer Reads

System Design Interview – BIGGEST Mistakes to Avoid

Meesho SDE-1 Online Assessment Interview Experience (Remote) - Rejected

Top 50 SQL Interview Questions and Answers (Beginner to Intermediate)

Spinny SDE-1 Interview Experience (Selected)

Meesho SDE-1 Backend Interview Experience (Remote | 3 Round) - Rejected

Blinkit (Eternal) SDE-1 Interview Experience (June 2026) – Offer Received

Uber SDE 2 Interview Experience (5 Rounds, Selected) - Complete DSA Questions with solution, System Design & Managerial Round

DSA Patterns for Coding Interviews: Complete LeetCode Roadmap (Beginner to Advanced)

Top 50+ SQL Interview Questions and Answers for Intermediate to Advanced

Amazon SDE II Interview Experience (Bangalore, Selected) ~ Aug 2026

Responses (1)

Write a response

Hide Comments

~ Raj Verma⏱️04 November 2025

---

Great insight article! It really helps to understand how things like dictionaries and sets might behave unexpectedly. you have explained clearly. it’s important, when working in C# to always override GetHashCode() if you override Equals().

Thanks for sharing!

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -53%

Zebronics #1 Best Seller

ZEBRONICS Blanc Slim Wireless Mouse — Rechargeable, BT + 2.4GHz (Black)

Up to 1600 DPI · Silent clicks · 63g · Multicolor LED

★★★★★★★★★★ 4.0 (9,512) 5K+ bought last month

₹376 M.R.P. ₹799Save ₹423

Buy Now →

‹ ›

‹ ›

‹ ›

‹ ›

Sponsored -34%

iQOO Amazon's Choice

iQOO Z10 Lite 5G — Cyber Green, 4GB RAM, 128GB Storage

Dimensity 6300 · 50MP Sony AI Camera · 6000 mAh · IP64

★★★★★★★★★★ 4.0 (2,052) 500+ bought last month

₹18,997 M.R.P. ₹28,999Save ₹10,002

Buy Now →

\n \n \n \n \n

Great insight article!\nIt really helps to understand how things like dictionaries and sets might behave unexpectedly. you have explained clearly. it’s important, when working in C# to always override GetHashCode() if you override Equals().

Thanks for sharing!

When working with collections like HashSet or Dictionary<TKey, TValue>, understanding the relationship between Equals() and GetHashCode()\nis critical. Many hidden bugs and performance problems in .NET apps happen because these two methods are used incorrectly.

Let’s unpack this in detail step by step.

The Role of Equals() and GetHashCode()

Every object in C# inherits two fundamental methods from System.Object:

\n
• public virtual bool Equals(object obj);
\n
• public virtual int GetHashCode();
\n

They work hand-in-hand to determine object equality and hash identity.

\n
• \n

  Equals() defines logical equality — when two objects mean the same thing.

  \n
\n
• \n

  GetHashCode() provides a hash used for fast lookups in hash-based collections (like HashSet, Dictionary and ConcurrentDictionary).

  \n
\n

How Hash-Based Collections Work

Collections like HashSet and Dictionary<TKey, TValue> are hash-based.\nThey use a two-step process for lookup and storage:

Hashing Phase:

\n
• Call GetHashCode() to compute an integer hash.
\n
• This determines which bucket an object belongs to.
\n

Equality Phase:

\n
• Once inside the right bucket, call Equals() to check if the item is actually equal to an existing entry.
\n

Example: HashSet Internals (Simplified)

Imagine a HashSet as multiple buckets (like small lists):

\nBucket 0: [ ]\nBucket 1: [ ]\nBucket 2: [Person(\"Alice\")]\nBucket 3: [ ]\nBucket 4: [Person(\"Bob\")]\n

When you add new Person(\"Alice\"):

\n
• \n

  The hash code decides which bucket to use.

  \n
\n
• \n

  Then Equals() ensures no duplicates exist in that bucket.

  \n
\n

If GetHashCode() returns different values for logically equal objects, they end up in different buckets and Equals() never even gets called to\ncompare them.

This is the Problem when Overriding Equals() but Not GetHashCode()

Consider this class:

\nclass Person\n{\n    public string Name { get; set; }\n\n    public override bool Equals(object obj)\n    {\n        return obj is Person other && Name == other.Name;\n    }\n\n    // ❌ Forgot to override GetHashCode()\n}\n

Let’s test it:

\nvar set = new HashSet<Person>();\nset.Add(new Person { Name = \"Dev\" });\nset.Add(new Person { Name = \"Dev\" });\n\nConsole.WriteLine(set.Count);  // Output: 2\n

Even though both objects are logically equal (Equals() returns true),\nHashSet stores both, because they have different hash codes.

Why It Happens

By default, GetHashCode() (from object) uses the object's reference in memory.\nSo, two different instances even with identical content, produce different hash codes.

Since the hash codes are different, the objects might end up in different buckets (bucketIndex = hashCode % capacity). In that case, the HashSet won’t even call Equals() to compare them. It only calls Equals() if both objects fall into the same bucket.

The Object Equality Contract

Microsoft’s official guidelines define a clear contract between Equals() and GetHashCode():

If two objects are equal (according to Equals()),\nthey must return the same value from GetHashCode().\n

Violating this rule leads to unpredictable behavior in any hash-based collection.

The Rules Summarized

.

Correct Implementation Example

Here’s how to fix it properly:

\nclass Person\n{\n    public string Name { get; set; }\n\n    public override bool Equals(object obj)\n    {\n        return obj is Person other && Name == other.Name;\n    }\n\n    public override int GetHashCode()\n    {\n        // Null-safe hash computation\n        return Name?.GetHashCode() ?? 0;\n    }\n}\n

Now test again:

\nvar set = new HashSet<Person>();\n\nset.Add(new Person { Name = \"Dev\" });\nset.Add(new Person { Name = \"Dev\" });\n\nConsole.WriteLine(set.Count);  // ✅ Output: 1\n

Now Equals() and GetHashCode() are consistent both objects hash to the same bucket and the duplicate is detected.

Real-World Impact

Here’s what can break if you don’t override both:

Performance Implications

Even if things seem to work, a broken hash implementation can:

\n
• \n

  Dramatically increase lookup time (because objects go into wrong buckets)

  \n
\n
• \n

  Cause memory waste (duplicate entries)

  \n
\n
• \n

  Lead to unpredictable behavior across different .NET versions or runtime optimizations

  \n
\n
• \n

  Hash-based collections rely on hash uniformity for performance — mismatched hashes kill that.

  \n
\n

How to Implement GetHashCode() Safely

A robust hash code implementation should:

\n
• \n

  Use immutable fields (values that don’t change after construction)

  \n
\n
• \n

  Combine multiple fields using a reliable hash combiner

  \n
\n
• \n

  Avoid overflow or randomization issues

  \n
\n

Example:

\nclass Employee\n{\n    public int Id { get; set; }\n    public string Department { get; set; }\n\n    public override bool Equals(object obj)\n    {\n        return obj is Employee e && Id == e.Id && Department == e.Department;\n    }\n\n    public override int GetHashCode()\n    {\n        return HashCode.Combine(Id, Department);\n    }\n}\n

.NET’s HashCode.Combine() (C# 8+) simplifies safe, high-quality hash generation.

Common Misconceptions

Summary

In Short

If you override Equals(), you must override GetHashCode().

Failing to do so may not crash your program,\nbut it will silently break correctness in ways that are hard to debug.

Example Summary in One Line

HashSet won’t even check equality between two objects unless their hash codes match.\n