Interview Questions on Singleton vs Static in C#

by

1. How does CLR manage memory differently for static classes and Singleton objects?

Static classes / static fields

A static type’s static fields are associated with the type loader and are effectively roots for the Garbage Collector (GC). When the runtime loads a type (usually at first access), the CLR runs the type initializer (static constructor) and allocates storage for its static fields in the AppDomain’s managed memory. In .NET Core and modern runtimes that notion maps to the process heap under the runtime’s memory management.

Static fields are considered GC roots as long as their containing type is loaded and the AppDomain is alive. In typical applications, AppDomain lives for the process lifetime, so static fields live until the process terminates. That means static objects are not eligible for GC while the AppDomain/type stay loaded.

Consequence: static usages can easily cause long-lived memory retention and leaks (for example static collections holding references).

Singleton instance

A well-implemented Singleton stores a reference in a static field, but the instance itself is a normal managed object on the heap, subject to GC rules. If the only strong reference to the instance is a root (a static field), then it behaves similarly (won’t be collected).

However, a key difference: a Singleton can be implemented with lazy creation (create instance only when needed) and can be designed to release references (for example, DI container disposing the instance when container is disposed) enabling GC under particular conditions (e.g., unload the service provider or set reference to null).

In short: both may be long-lived if referenced by static roots; Singleton offers more options for controlled lifetime (lazy init, explicit disposal, DI container control) while static fields are essentially permanent for the AppDomain lifetime.

Practical tip: prefer DI-managed singletons over raw static fields for lifetimes you may need to control.

2. Can a static class hold state? What are the dangers if it does?

Yes — but it’s usually a bad idea. Static classes can (and often do) contain static fields and properties, which are state that is global for the AppDomain.

Dangers and consequences:

Global mutable state

Static state is global and can be changed from anywhere in code, leading to unpredictable behavior and hidden coupling across modules.

Thread-safety issues

Multiple threads updating static fields can cause race conditions unless you add synchronization (locks, Interlocked operations).

Testing complexity

Static state cannot be easily isolated or reset for unit tests. It makes tests order-dependent and brittle.

Memory leaks

Static references prevent GC of referenced objects, causing leaks (especially when storing large caches or event delegates).

Violation of SOLID principles

Static state breaks Dependency Inversion and Single Responsibility — callers directly depend on concrete static implementations.

Hard to version/extend

Since static classes cannot implement interfaces or be inherited, refactoring or substituting implementations becomes hard.

When static state is acceptable:

  • Truly constant data (e.g., public const string AppName = "X"), or read-only static data initialized once and never modified. Even then, prefer readonly and immutable types.

Recommendation: minimize static mutable state; if you need global shared state, use a Singleton/DI-managed service with controlled synchronization and lifecycle.

3. How would you implement a thread-safe lazy Singleton in a high-concurrency application?

Answer (detailed with code patterns):

There are several idiomatic approaches. The safest and simplest is Lazy<T> in .NET:

Preferred approach: Lazy<T>

public sealed class MySingleton
{
    private static readonly Lazy<MySingleton> _lazy =
        new Lazy<MySingleton>(() => new MySingleton(), isThreadSafe: true);

    private MySingleton() { /* init heavy resources */ }

    public static MySingleton Instance => _lazy.Value;
}
  • Lazy<T> handles thread-safety by default (if you pass true or use the default constructor).
  • Guarantees only one instance even under high concurrency.
  • Supports lazy initialization and exception caching semantics (exceptions thrown during initialization are rethrown on subsequent accesses unless you choose different LazyThreadSafetyMode).

Double-checked locking (manual)

public sealed class MySingleton2
{
    private static MySingleton2 _instance;
    private static readonly object _lock = new object();

    private MySingleton2() { }

    public static MySingleton2 Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_lock)
                {
                    if (_instance == null)
                        _instance = new MySingleton2();
                }
            }
            return _instance;
        }
    }
}
  • Works when _instance is declared volatile in older frameworks to prevent reordering issues; in C# volatile or memory barriers are recommended to be safe. Lazy<T> avoids such gotchas.

Static readonly initialization (eager)

public sealed class MySingleton3
{
    private static readonly MySingleton3 _instance = new MySingleton3();
    private MySingleton3() { }
    public static MySingleton3 Instance => _instance;
}
  • Guaranteed thread-safe since .NET type initialization is thread-safe. But it’s eager (created at type initialization time).

Additional considerations for high concurrency:

  • Avoid locking on public objects; use private locks.
  • Minimize lock scope; only protect initialization.
  • Consider using LazyThreadSafetyMode.ExecutionAndPublication or PublicationOnly depending on how you want exceptions and multiple initializations to be handled.
  • If initialization is heavy and can fail, consider a safe retry strategy or separate initialization method.

Recommendation: Use Lazy<T> for simplicity and correctness in multi-threaded environments.

4. Why is Singleton preferred over static classes in modern ASP.NET Core applications?

Dependency Injection (DI) and composition

ASP.NET Core uses built-in DI thoroughly. Singletons can be registered and resolved via DI: services.AddSingleton<IMyService, MyService>();

This allows you to declare dependencies (constructor injection), making life-cycle and configuration consistent, testable, and explicit.

Testability

A Singleton implementing an interface can be mocked or replaced during unit tests. Static classes are hard-coded and cannot be injected, making isolation difficult.

Abstraction & Polymorphism

Singleton classes can implement interfaces, derive from base classes, and expose stateful behavior. Static classes cannot.

Controlled lifetime & disposal

DI containers manage instance disposal (if IDisposable), allowing graceful cleanup. Static classes lack automatic disposal mechanisms.

Configuration & Extensibility

Singletons can accept settings via constructor parameters or factory patterns, enabling flexible configuration.

Reduced global coupling

Using DI and singletons reduces global reachability — you inject what you need instead of accessing global static state.

When static might still be used in ASP.NET Core:

Stateless helper methods (e.g., Path.Combine) — small pure functions that do not require DI or state.

Summary: In ASP.NET Core’s modular, test-driven, DI-centric world, Singletons fit naturally into architecture while static classes do not.

5. Can Singleton objects be garbage collected? Under what conditions?

Answer (detailed):

Normally not, if the Singleton instance is referenced by a static field. In typical implementations, the Instance property returns a static field which is a GC root — therefore the GC will not collect it while the AppDomain is alive.

Conditions where it can be collected:

Reference removed — if you explicitly set the static reference to null, the instance becomes eligible for GC (assuming no other references). // Example: MySingleton.Clear(); typeof(MySingleton).GetField("_instance", BindingFlags.NonPublic | BindingFlags.Static).SetValue(null, null); (Reflection aside, designing an API to clear the instance must be done carefully.)

DI container disposal — if the Singleton is not stored in a static field but managed by a DI container, disposing the container may release the final references, enabling collection.

Unloading AssemblyLoadContext / AppDomain — in .NET Core, unloading an AssemblyLoadContext that holds a type with static references can release those static roots. In classic .NET Framework, unloading an AppDomain does it. This is advanced and rare.

WeakReference-based singletons — if you store the instance behind a WeakReference<T>, GC can collect it if no strong references exist. But this loses the guarantee of a single persistent instance.

Important caveat: making a Singleton collectible undermines the typical expectation of “always-present” instance — design choices must be explicit and documented.

6. In what scenarios would using a static class cause memory leaks?

Answer (detailed):

Static classes (or static fields) can cause memory leaks because static references are GC roots. Common leaking scenarios:

Static collections that keep growing

Example: static List<object> Cache. If items are added and never removed, memory grows indefinitely.

Static event handlers

If an object subscribes to a static event and the handler is an instance method, the static event’s delegate holds a reference to that instance, preventing its collection.

Example: public static class Emitter { public static event EventHandler Something; } // Subscriber instance subscribes -> cannot be GC'd until unsubscribed

Static caches holding large objects

Large images, DB results, or byte arrays kept in statics without eviction logic lead to leaks.

Static references to long-lived unmanaged resources

Holding Stream or IDisposable objects statically without disposal causes resource exhaustion.

Incorrect use of Task or async results stored statically

E.g., static Task _backgroundTask capturing closures that hold onto large objects.

Static delegates / expressions capturing closures

Captured variables may keep entire object graphs alive.

Mitigation strategies:

  • Use WeakReference for caches where appropriate.
  • Implement eviction strategies (LRU) for static caches.
  • Unsubscribe event handlers or use weak event patterns (WeakEventManager).
  • Prefer DI-managed singletons where lifetime can be controlled and disposable patterns followed.
  • Keep static usage to immutable/read-only data.

7. Can we implement polymorphism using a static class? Why or why not?

No. Static classes are types that cannot be instantiated, cannot participate in inheritance, and cannot implement interfaces. Polymorphism in OOP depends on instances and virtual/abstract members resolved at runtime through vtables or interface dispatch. Static members are resolved at compile time (type-level), not instance-level.

Reasons:

  1. No instances — polymorphism operates on references to objects (base class or interface) pointing to different concrete instances. Static classes do not produce instances.
  2. No virtual methods — static methods cannot be virtual or abstract and therefore cannot be overridden.
  3. No interface implementation — you cannot write public static class MyStatic : IFoo { }.

Workarounds and alternatives:

  • Use instance classes implementing interfaces and register them as DI services or Singletons.
  • If you need “static-like” free functions with polymorphism, expose an interface with instance methods and offer a default static-like singleton that implements it.

Conclusion: when you need polymorphism, use instance types + interfaces (e.g., Singleton implementing ILogger) — not static classes.

8. What is the impact of static classes on unit testing compared to Singleton?

Static classes

Hard to mock: Most mocking frameworks rely on substituting instances or interfaces; static methods cannot be substituted or injected.

Hidden dependencies: Code that calls static methods hides its dependencies, making unit tests harder to isolate — you often need to run integration-style tests.

State leakage: Static state persists across tests, making tests order-dependent unless you reset static state manually.

Workarounds: Use wrappers/facades — create an interface and an adapter that calls the static class, then mock the adapter in tests. Example: IFileSystem wrapper around static File methods.

Singleton

Mockable if designed with interface: If the Singleton implements an interface (IMyService), you can register a test/mock instance with the DI container or inject a mock object.

DI-friendly: Using DI to provide the Singleton allows easy substitution with test doubles per test scope.

However: A Singleton that is accessed via a static Instance property and not via DI still causes test difficulties. So it’s Singleton + DI that yields testability.

Best practice: Prefer DI-registered singletons over static classes for testability. If you must use static, wrap with an interface for testing.

9. How do static constructors differ from Singleton constructors?

Answer (detailed):

Static constructor (type initializer)

Syntax: static MyClass() { ... }

Run once per type, automatically by the CLR before the type is first used (first reference to any static member or before an instance is created).

No parameters, cannot be public/private (implicitly private), and cannot be called directly.

It’s guaranteed to be thread-safe by the CLR (the runtime ensures only one thread runs it).

If static constructor throws an exception, the type becomes unusable — TypeInitializationException for the remainder of the AppDomain lifetime.

Singleton private constructor

Syntax: private MySingleton() { ... }

Called when the code creates the instance (explicitly or via Lazy<T>).

Can accept no/limited parameters but typically parameterless for DI-less implementations.

You control when it runs (eagerness vs laziness).

You can implement exception-handling or retry logic inside the factory that constructs the singleton. Exceptions during creation can be handled differently (e.g., log and try again).

Consequences:

  • Static constructor timing is automatic and tied to type access; singleton construction is under program control (and can be lazy or eager).
  • Static constructor is simpler but less flexible; Singleton constructors give you options like dependency injection, disposal, and controlled retries.

10. What are common anti-patterns associated with Singleton usage?

Answer (detailed):

Singleton is useful but commonly misused. Common anti-patterns:

  1. God Object
    • A Singleton that accumulates too many responsibilities becomes a monolithic “god” object, violating Single Responsibility and making code brittle.
  2. Hidden Dependencies
    • Code calls MySingleton.Instance directly; dependencies are hidden and not expressed through constructor injection, making code less modular and harder to test.
  3. Global Mutable State
    • Using a Singleton as a global variable for mutable data leads to the same problems as static state: race conditions, coupling, and testing issues.
  4. Tight Coupling to Implementation
    • Consumers depend on concrete Singleton type instead of abstractions (interfaces), making refactoring difficult.
  5. Singleton for everything
    • Overusing Singleton for trivial services that would better be scoped or transient causes unnecessary lifetime and resource management complexity.
  6. Stateful Singletons without locking
    • Accessing mutable fields of singletons without synchronization in multi-threaded apps leads to data corruption.
  7. Improper disposal
    • Singletons holding unmanaged resources without IDisposable support or not disposed correctly (maybe due to static references) can leak resources.

Avoid these by:

  • Limiting responsibilities
  • Using interfaces + DI
  • Choosing correct lifetime (transient/scoped/singleton)
  • Implementing thread-safety and disposal

11. How would you refactor an over-used static utility class into DI-friendly services?

Refactoring static-heavy code into DI-friendly services improves testability and maintainability. Steps:

  1. Identify responsibilities
    • Break the large static utility into smaller coherent sets of responsibilities (SRP). For example, FileHelpers, StringHelpers, ValidationHelpers.
  2. Define interfaces
    • For each responsibility, create an interface, e.g., IFileHelper, IValidationService.
  3. Create instance-based implementations
    • Convert static methods into instance methods on classes implementing the interfaces. Use constructor injection for dependencies.
    public interface IFileHelper { bool Exists(string path); } public class FileHelper : IFileHelper { public bool Exists(string path) => File.Exists(path); }
  4. Register services in DI
    • services.AddSingleton<IFileHelper, FileHelper>(); or choose scope accordingly.
  5. Replace static calls with injected services
    • Update consumers to accept the interface via constructor injection instead of calling static methods directly.
  6. Add tests
    • Mock interfaces in unit tests using a mocking framework and verify behavior.
  7. Provide a compatibility façade (optional)
    • If many places use the static API and refactoring all at once is risky, create a static façade that delegates to the DI service (retrieved from a global service provider) — transitional pattern only.
  8. Gradual rollout
    • Replace critical areas first and progressively migrate all calls.

Benefits: enables mocking, centralized lifecycle, better SRP compliance, easier refactor and testing.

12. In a distributed microservices architecture, is Singleton still valid? Why or why not?

Local validity only. A Singleton is only a single instance per process (per AppDomain or per Service Process). In a distributed system with multiple service instances (containers / VMs), each process has its own Singleton instance; there is no cross-process enforcement.

Implications:

  1. No global uniqueness across nodes
    • You cannot rely on an in-process Singleton for global coordination (e.g., “only one job runs across the cluster”).
  2. Use distributed coordination for global singleton needs
    • For cross-process singletons, use an external centralized store/services such as Redis locks, distributed leader election (Zookeeper/Consul), or a database row lock.
  3. Use local singleton for local caching or per-instance resources
    • It’s valid to use Singleton for local caches or resources that should be shared within one process.
  4. Multi-tenant considerations
    • Per-tenant singletons would require mapping tenant context to in-process instances or using DI scopes per tenant; global singletons won’t separate tenant data.

Conclusion: Use in-process singleton patterns where the scope is the process; for global coordination across distributed services, adopt distributed locking/consensus mechanisms.

13. Can you use async/await inside a static class or Singleton class?

Yes, you can use async/await in both static methods and instance methods (including those on Singleton). But there are design and concurrency implications.

Static class considerations:

  • Static async methods are fine for stateless operations: public static async Task<string> FetchAsync(string url) { ... }
  • Danger: static methods that access static mutable state must be made thread-safe. Async methods introduce concurrency interleaving; using non-thread-safe shared state can cause races.

Singleton considerations:

  • Instance async methods are fine and often preferable because the Singleton can hold state and synchronization primitives: public class Service { public async Task InitializeAsync() { ... } }
  • Async initialization pattern: Some objects require asynchronous initialization (e.g., warm up caches). You can use Lazy<Task<T>> or AsyncLazy patterns.

Async singleton initialization pattern:

private static readonly AsyncLazy&lt;MySingleton> _lazy =
    new AsyncLazy&lt;MySingleton>(async () => { var s = new MySingleton(); await s.InitializeAsync(); return s; });

public static Task&lt;MySingleton> InstanceAsync() => _lazy.Task;

(You can implement AsyncLazy<T> using Lazy<Task<T>>.)

Pitfalls:

  • Avoid .Result or .Wait() on tasks in synchronous code — can cause deadlocks in certain synchronization contexts (UI apps).
  • Ensure proper exception handling — exceptions in async initialization are propagated through Task and must be observed.

Summary: async/await works; be cautious about shared state, initialization ordering, and deadlocks.

14. How does multithreading affect static members vs Singleton members?

Both static members and Singleton instance members are shared across threads in a process and therefore require synchronization when mutable.

Static members:

  • Static fields are globally shared; concurrent reads are safe for immutable data but writes must be synchronized.
  • Because statics are globally accessible, it’s easy to forget to add synchronization leading to race conditions.
  • Example risk: static int counter; — incrementing without Interlocked.Increment is a race.

Singleton members:

  • Singleton instance fields are shared the same way; since only one instance exists, concurrent access must protect mutable state.
  • Singleton has the advantage of being able to encapsulate locking logic (private lock object) and control concurrency within instance methods.
  • Singleton methods can have instance-level synchronization rather than global static locks — often more natural and testable.

Thread-safety patterns:

  • Immutable state is best: design objects to be immutable where possible.
  • Use lock with private object _sync = new object() or ReaderWriterLockSlim for complex scenarios.
  • Use atomic operations: Interlocked.Increment, CompareExchange.
  • Use concurrent collections: ConcurrentDictionary, ConcurrentQueue etc.
  • For per-call independent operations, avoid shared state entirely.

Tip: Document the thread-safety model (e.g., “this class is thread-safe” or “caller must synchronize”) so callers know expectations.

15. Why is static class suitable for pure utility libraries but not for business services?

Utility libraries (pure functions):

Static classes are ideal when functions are stateless, deterministic, and side effect free (pure). Examples: Math, string formatting helpers, small conversion utilities.

Advantages: simple usage (StringHelper.ToTitleCase()), no need for instantiation, fast and easy.

Business services:

Business services often have state, configuration, dependencies, and lifecycle — all of which require:

Dependency injection (to vary implementations or provide collaborators)

Testability (mocking and isolation)

Lifecycle management (disposal, scoping)

Polymorphism (multiple implementations or strategies)

Static classes cannot express these requirements. They produce tight coupling, hidden dependencies, and hamper unit testing.

Example: A payment service needs logging, a gateway client, configuration settings, and possible a scoped transaction. Implementing it as a static class would create many coupling and testability problems.

Conclusion: static classes are suitable for pure, stateless utilities; for any business logic that involves dependencies, state, or lifecycle, prefer instance-based services (Singleton/transient/scoped via DI).

16. Describe a scenario where using static class will break SOLID principles.

Scenario: You implement an OrderProcessor as a static class:

public static class OrderProcessor
{
    public static void Process(Order o)
    {
        // validate order
        // check inventory (direct DB calls)
        // charge payment (directly contact payment gateway)
        // send emails
    }
}

How SOLID principles are violated:

  1. Single Responsibility Principle (SRP)
    • OrderProcessor does validation, inventory, payment, and notification all in one method. It has multiple responsibilities—hard to maintain and change.
  2. Open-Closed Principle (OCP)
    • You cannot easily extend behavior (e.g., support new payment gateways) without modifying the static method.
  3. Liskov Substitution Principle (LSP)
    • Static class cannot be substituted with a different implementation. No polymorphism possible.
  4. Interface Segregation Principle (ISP)
    • No interfaces exist; clients cannot depend on smaller, focused abstractions.
  5. Dependency Inversion Principle (DIP)
    • High-level logic depends on low-level concrete mechanisms (DB, payment) directly inside static code rather than on abstractions injected in.

Consequences: Tight coupling, hard-to-test logic, brittle codebase.

Refactor approach: Introduce interfaces (IInventoryService, IPaymentGateway, INotificationService), implement them as services, and register as DI-enabled classes. OrderProcessor becomes an instance service injected with these dependencies — aligning with SOLID.

17. When should you avoid Singleton pattern completely?

Avoid Singleton when:

  1. Frequent state changes needed per request/user
    • Singletons shared across all requests will mix state; better to use scoped/transient services.
  2. Per-user or per-tenant data
    • Singletons cannot safely hold user-specific state. Use scoped services (per request) or per-tenant scoped instances.
  3. High GC pressure or high memory churn
    • If a singleton manages large buffers that frequently change, memory behavior can be suboptimal. Consider buffering strategies or pooled resources.
  4. Multiple implementations expected
    • If you might need multiple implementations or conditional binding, prefer DI with scoped/transient lifecycles.
  5. Cluster-wide uniqueness required
    • If the requirement is “only one instance across all machines,” Singleton is inappropriate (it’s in-process only).
  6. Uncontrolled side effects
    • When initialization side-effects are risky or you need predictable startup/shutdown semantics — singletons with static instances can complicate this.
  7. Complex testing scenarios
    • If tests need to run in parallel with isolated state, global singletons make isolation hard.

Preferred alternatives: scoped services (per request), transient services (per consumer), or well-managed factory/registry patterns.

18. What is the difference between static readonly instance vs Singleton instance?

Answer (detailed):

Often people implement a “singleton” as a static readonly field:

public sealed class Foo
{
    public static readonly Foo Instance = new Foo();
    private Foo() { }
}

Differences and considerations:

  • Creation time
    • static readonly instance is created at type initialization (eager), which happens on first access to the type. This can be fine but removes lazy init benefits.
    • Singleton patterns can be lazy (using Lazy<T>), creating the instance only when needed.
  • Disposal & lifecycle
    • Static readonly does not easily support disposal — the static field will remain until AppDomain unload. Singleton implemented as an instance can be controlled by DI and disposed when container is disposed.
  • Abstraction & testability
    • Both patterns can be equally unmockable if accessed via Foo.Instance directly. But a Singleton that implements an interface and is registered in DI is more test-friendly.
    • Static readonly instance cannot implement interfaces in a way that helps DI.
  • Exception behavior
    • Exceptions during static initialization (static constructor) may make the type unusable. Lazy singleton can handle failures more flexibly.
  • Memory and performance
    • Both occupy memory when created. With static readonly you pay cost at first type access; with lazy singleton you delay cost to first Instance use.

Bottom line: static readonly is a simple eager singleton variant but lacks flexibility (lazy loading, disposal, DI-friendliness).

19. How can a Singleton support multiple instances in a multi-tenant application?

If you need one instance per tenant (not one per process), the classic Singleton pattern must be adapted because it enforces a single instance across the entire process. Strategies:

  1. Per-tenant registry/factory (dictionary keyed by tenant id)
    • Maintain a thread-safe dictionary mapping tenant id → instance. On first access for a tenant, create instance and store it.
    public static class TenantSingletonFactory { private static readonly ConcurrentDictionary<string, MyService> _map = new(); public static MyService Get(string tenantId) => _map.GetOrAdd(tenantId, id => new MyService(id)); }
    • Pros: Simple. Cons: need eviction for tenants that go away; memory may grow.
  2. DI scoped services per tenant scope
    • Create a DI scope per tenant and register services for that scope. Maintain a scope-per-tenant lifecycle and resolve services from that scope.
    • Pros: integrates with DI disposal. Cons: complexity in managing scopes.
  3. Use tenant-aware factory
    • Instead of a global singleton, create a factory service that returns a tenant-specific cached instance.
  4. Use keyed Singletons via a provider
    • Similar to registry but encapsulated behind an interface, enabling testing.
  5. Cache with eviction
    • Use MemoryCache with sliding/absolute expiration to manage instances for tenants that are infrequently used.
  6. Externalized per-tenant state
    • For some cases, use an external distributed cache (Redis) for tenant-specific shared data, while keeping per-tenant lightweight instances in memory.

Design considerations:

  • Always plan for tenant lifecycle (creation/deletion).
  • Implement eviction and memory limits.
  • Ensure thread-safety in factory/registry.
  • Use interfaces and DI where possible for testability.

20. Does using static class improve performance? If yes, how?

Yes, in some narrow cases. Static classes can yield small performance benefits due to:

No allocation cost for objects — methods on static classes are called on the type directly without instance creation.

Potential inlining and JIT optimization — static methods are often easier for the JIT to inline because they have no instance parameter, potentially reducing call overhead.

Lower memory footprint for tiny, stateless helpers compared to creating many short-lived objects.

However — the benefits are typically marginal:

  • For most real applications, the difference between a static method call and calling a cached instance method is negligible.
  • Performance wins from static usage are outweighed by losses through decreased maintainability, testability, and increased bugs due to shared state.

When performance matters:

  • High-performance low-level libraries (math libraries, tight loops) sometimes use static operations to avoid allocations.
  • Micro-optimizations: prefer structs or pooled objects rather than static state when allocation pressure is the real problem.

Recommendation: prioritize clean design and testability. Only micro-optimize with static when profiling indicates it’s necessary and safe.

21. What are pitfalls of using Singleton in multithreaded applications?

Singletons in multi-threaded programs can introduce several pitfalls:

  1. Improper lazy initialization
    • If not implemented thread-safely, multiple threads may create multiple instances concurrently. Use Lazy<T> or double-check locking with correct memory semantics.
  2. Lock contention
    • Overuse of locks inside singleton methods can hurt scalability when many threads access the singleton simultaneously. Design fine-grained locks or use lock-free structures.
  3. Deadlocks
    • If Singleton methods acquire locks or call out to other services that in turn try to access the singleton, circular lock dependencies can cause deadlocks.
  4. State corruption
    • Mutable shared state without synchronization leads to inconsistent state visible to threads.
  5. Initialization exceptions
    • Exception during initialization cached by Lazy<T> may leave the system in a bad state; plan fallback or retry semantics.
  6. Hidden expensive operations
    • A synchronous heavy initialization that runs on first access can cause thread starvation. Use asynchronous initialization patterns (e.g., Lazy<Task<T>>) or ensure initialization is cheap.
  7. Performance bottleneck
    • If the singleton encapsulates a heavily contended resource, it becomes a bottleneck. Consider sharding resources or using per-thread or per-scope instances.

Mitigations:

  • Use Lazy<T> for thread-safe lazy initialization.
  • Keep methods reentrant and avoid global locks for frequently invoked operations.
  • Use concurrent collections (ConcurrentDictionary) and atomic operations.
  • Document thread-safety and design for concurrency from the start.

22. How does ASP.NET Core handle Singleton lifetime in DI container?

  • In ASP.NET Core DI:
    • services.AddSingleton<TService, TImplementation>() registers a single instance of TImplementation for the lifetime of the IServiceProvider (typically the application lifetime).
    • The DI container will create the instance once (either eagerly at startup if you register an instance or lazily on first resolve) and reuse it for all subsequent resolutions.

Key points:

  1. One instance per IServiceProvider
    • If you create child service providers, each provider may get its own singleton instance.
  2. Disposal
    • If the singleton implements IDisposable, the DI container disposes it when the container is disposed (e.g., during application shutdown).
  3. Thread-safety
    • Because singletons are shared across requests, they must be thread-safe if mutable.
  4. Best practices
    • Avoid capturing IServiceProvider in a singleton to request scoped services — doing so may cause resolved scoped dependencies to live beyond their intended scope. If a singleton needs a scoped service occasionally, consider a factory pattern or IServiceScopeFactory to create appropriate scopes.
  5. Registration variations
    • AddSingleton<TService>(provider => new MyService(...)) — use factory to control how singleton is constructed, possibly grabbing configuration and other services at registration time.

Example:

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<ICacheManager, MemoryCacheManager>();
}

Summary: The DI-managed singleton integrates lifecycle management and disposal, making it preferable to manual static singletons in ASP.NET Core.

23. Why can’t static classes be passed as parameters, but Singleton objects can?

Static class is a type, not an instance. Parameters are values or object references. Passing a static class would be passing a type token — the runtime method signatures expect instance references or values, not types. You can pass Type objects (reflection), but that isn’t the same.

Singleton is an instance — it is an object reference (MySingleton.Instance) and can be passed to methods like any other object. Passing an instance allows polymorphism (you can accept interfaces or base classes). You can mock or substitute instances during tests.

Implications:

  • With instance parameters you express explicit dependencies — better for design and testing.
  • Static classes enforce dependency on type, not on an interface, hiding dependencies and preventing substitution.

Conclusion: For flexible architecture, pass interfaces/instances (Singletons via DI), not static types.

24. How to convert a static method library into a Singleton without breaking existing apps?

A pragmatic migration strategy (backward-compatible):

  1. Create an interface
    • Define an interface that represents the service (e.g., IMathService).
  2. Implement instance-based class that wraps previous static logic
    • New class MathService : IMathService internally calls the static helpers or contains equivalent logic.
  3. Provide a static façade that delegates to DI or default singleton
    • Keep the old static API, but inside delegate to the new instance. For example:
    public interface IMathService { double Sqrt(double v); } public class MathService : IMathService { public double Sqrt(double v) => MathHelpers.Sqrt(v); // or direct impl } public static class MathHelpers // old API { private static IMathService _impl = new MathService(); public static void SetImplementation(IMathService impl) => _impl = impl; public static double Sqrt(double v) => _impl.Sqrt(v); }
    • Optionally on application startup, set _impl from DI container: MathHelpers.SetImplementation(provider.GetService<IMathService>());
  4. Register new service in DI
    • services.AddSingleton<IMathService, MathService>();
    • On application bootstrap, wire static façade to DI-provided instance.
  5. Gradually refactor callers
    • New code should depend on IMathService and use constructor injection.
    • Existing code using MathHelpers will continue to work.
  6. Deprecate static façade
    • After migrating callers, mark facade deprecated and remove it in a major release.

Advantages:

  • No breaking changes for existing apps.
  • Allows testability and DI for new code.
  • Gradual migration reduces risk.

25. How does static method binding differ from Singleton method binding at runtime?

Static method binding

Static methods are type-level and are bound at compile-time to the method implementation (early binding), though the JIT might inline or optimize them at runtime. There is no virtual dispatch for static methods.

Calls are resolved to a specific method on the type and do not involve vtable or interface dispatch.

Singleton instance method binding

Instance methods (especially virtual or interface methods) use runtime dispatch (vtable or interface dispatch) enabling polymorphism. If Singleton implements IMyService and the consumer uses the interface, the actual method invoked can be determined at runtime allowing substitution.

If the method is non-virtual instance method, it is still bound to a particular method but requires an instance reference.

Impacts:

  • Polymorphism & extensibility: Singleton instance methods that are virtual or accessed via interface allow runtime substitution and overrides; static methods do not.
  • Mocking & testing: Instance methods resolved through interfaces can be mocked; static methods cannot.
  • Performance: static calls can be slightly faster (no instance pointer, potential inlining) but differences are usually minor and not dominant compared to design benefits of instance-based methods.

Closing notes & study advice

  • For interview prep: explain trade-offs — don’t just state facts. Show when static is acceptable (pure utilities) and when Singletons (DI-managed) are better (testability, lifecycle).
  • Be ready to discuss concurrency, memory, DI, scoping, and real-world migrations — those are the areas interviewers probe.
  • If asked for code, prefer Lazy<T> or DI AddSingleton<T> examples and emphasize thread-safety, IDisposable, and testing patterns.

Leave a Comment