You’ve built your .NET Core API. The architecture is clean, the database is indexed, and locally, the application responds in milliseconds. But the moment you deploy to production and concurrent user traffic ramps up, things take a mysterious turn. Requests begin to queue, CPU usage spikes without warning, and API response times grind to an excruciating halt.
You might assume you need more server resources, but the real culprit is often hiding in plain sight: misused async and await keywords.
While Microsoft’s introduction of async/await revolutionized asynchronous programming by making it incredibly easy to read and write, it also made it dangerously easy to misuse. When we treat asynchronous programming as just “adding two magic words to our methods,” we inadvertently introduce bottlenecks, memory leaks, and thread pool starvation into our applications.
If you want to ensure your .NET Core applications scale efficiently, it’s time to stop making these common asynchronous mistakes. Here is a deep dive into the most pervasive async/await misuses that are quietly killing your app’s performance, and exactly how to fix them.
1. The Deadly “Sync-Over-Async” Trap (.Result and .Wait())
The single most destructive thing you can do to a .NET Core web application is forcing an asynchronous operation to run synchronously. This is commonly known as “sync-over-async.”
Developers usually fall into this trap when they are working inside a legacy synchronous method and need to call a new asynchronous library, using .Result or .Wait() to force the task to finish before moving on.
The Problem: When you call await, you are telling the .NET Thread Pool: “I am waiting for an external resource (like a database or API). Take this thread and go serve another user’s request until I get my data back.” But when you call .Result or .Wait(), you completely defeat this mechanism. You are actively blocking the current thread and holding it hostage until the background operation completes. In high-traffic scenarios, your application quickly runs out of available threads to handle new incoming HTTP requests.
The Bad Code:
public User GetUser(int id)
{
// ❌ TERRIBLE: Blocks the thread, risks deadlocks, and causes thread starvation.
var user = _userRepository.GetUserAsync(id).Result;
return user;
}
public async Task<User> GetUserAsync(int id)
{
// ✅ GOOD: Frees the thread to handle other requests while waiting.
var user = await _userRepository.GetUserAsync(id);
return user;
}
2. Using async void Anywhere But Event Handlers
The async void signature is the silent crasher of .NET applications.
When you return a Task from an async method, any exceptions thrown inside that method are safely captured by the Task object. The calling method can then await the task, catch the exception using a standard try/catch block, and handle it gracefully.
The Problem: If a method is async void, there is no Task object returned to capture the exception. If an error occurs, the exception escapes the method’s context and goes straight to the active SynchronizationContext or the thread pool. In ASP.NET Core, an unhandled exception from an async void method will bypass your global exception handling middleware and completely tear down the application process.
The Bad Code:
// ❌ TERRIBLE: If SaveAsync throws, your entire application process crashes.
public async void FireAndForgetSave()
{
await _database.SaveAsync();
}
async void. Always return Task.// ✅ GOOD: Exceptions are safely encapsulated in the returned Task.
public async Task FireAndForgetSaveAsync()
{
await _database.SaveAsync();
}
3. Sequential Awaits in Loops (Ignoring Task.WhenAll)
A major benefit of asynchronous code is the ability to run independent operations concurrently. However, a very common mistake is processing independent asynchronous tasks sequentially inside a loop.
The Problem: If you have to fetch data for 5 different users, and each network request takes 1 second, awaiting them one-by-one inside a foreach loop will take 5 seconds. You are wasting time waiting for Task A to finish before you even start Task B, even though Task B doesn’t rely on Task A.
The Bad Code:
// ❌ BAD: Takes 5 seconds total.
var users = new List<User>();
foreach (var id in userIds)
{
// Blocks the loop until this specific task finishes.
users.Add(await FetchUserByIdAsync(id));
}
Task objects, and await them concurrently using Task.WhenAll().// ✅ GOOD: Takes ~1 second total. var userTasks = userIds.Select(id => FetchUserByIdAsync(id));
// Awaits all tasks simultaneously. var users = await Task.WhenAll(userTasks);
4. Wasting Memory: Overusing Task<T> Instead of ValueTask<T>
Every time an async method returning a Task<T> is called, .NET must allocate a new object on the managed heap. Under normal circumstances, this is a negligible performance cost. However, in highly optimized, “hot path” code where a method is called thousands of times per second, these heap allocations force the Garbage Collector (GC) to work overtime, resulting in CPU spikes and application pauses.
The Problem: If an async method frequently completes synchronously (for example, reading from an in-memory cache before falling back to a database), returning a Task<T> creates an entirely unnecessary heap allocation.
The Fix: Use ValueTask<T>. Because ValueTask<T> is a struct (a value type), it is allocated on the stack rather than the heap. If the method completes synchronously, there is zero memory allocation overhead.
// ✅ GOOD: Prevents heap allocations if the value is already cached.
public async ValueTask<User> GetUserAsync(int id)
{
if (_cache.TryGetValue(id, out var user))
{
return user; // Zero allocation synchronous return
}
// Fall back to actual async work
return await _database.GetUserAsync(id);
}
Note: ValueTask has specific consumption rules (you should only await it once). Use it strategically on high-throughput paths, not as a blanket replacement for Task.
5. Misunderstanding Task.Run for I/O Operations
There is a massive misconception that wrapping synchronous code in Task.Run() magically makes it asynchronous and highly scalable.
The Problem: Task.Run is designed to offload heavy CPU-bound work (like complex math calculations or image processing) to a background thread so the main UI thread doesn’t freeze.
In an ASP.NET Core web application, offloading an I/O-bound operation (like a database call) to Task.Run is incredibly counterproductive. You are simply taking a thread pool thread, handing the work to another thread pool thread, and making the original thread wait. This introduces unnecessary thread context switching and burns through your thread pool twice as fast.
The Bad Code:
public async Task<string> ReadFileAsync()
{
// ❌ BAD: Wastes a thread just to pretend this is async.
return await Task.Run(() => File.ReadAllText("data.txt"));
}
The Fix: Use natively asynchronous APIs provided by .NET.
public async Task<string> ReadFileAsync()
{
// ✅ GOOD: True async I/O. No extra threads consumed.
return await File.ReadAllTextAsync("data.txt");
}
6. The try/using Eliding Trap
“Eliding” the async/await keywords means returning a Task directly from a method without awaiting it. This saves the .NET compiler from generating a complex state machine behind the scenes, offering a tiny performance boost.
// Acceptable eliding: public Task<string> GetDataAsync() => _httpClient.GetStringAsync(url);
The Problem: Developers often try to be clever and elide the await keyword inside using blocks or try/catch blocks. If you return a Task directly from inside a using block without awaiting it, the method immediately disposes of the resource before the asynchronous operation has actually finished executing!
The Bad Code:
public Task<string> FetchDataAsync()
{
using var client = new HttpClient();
// ❌ TERRIBLE: 'client' will be disposed before the HTTP call finishes!
return client.GetStringAsync("https://api.com");
}
The Fix: If you are inside a using block or a try/catch block, you must use the await keyword.
public async Task<string> FetchDataAsync()
{
using var client = new HttpClient();
// ✅ GOOD: Awaits the task completely before disposing the client.
return await client.GetStringAsync("https://api.com");
}
Conclusion
Asynchronous programming in .NET Core is an incredibly powerful tool for building scalable, high-throughput applications. But async/await is not a magic wand. Treating it as such often leads to blocked threads, application crashes, and heavy garbage collection cycles.
By eliminating sync-over-async blocking, abolishing async void, parallelizing your loops with Task.WhenAll, and understanding when to leverage ValueTask, you can ensure your API is utilizing server resources exactly as intended. Keep your threads free, your memory footprint low, and your response times blazing fast.
Yury Sobolev is Full Stack Software Developer by passion and profession working on Microsoft ASP.NET Core. Also he has hands-on experience on working with Angular, Backbone, React, ASP.NET Core Web API, Restful Web Services, WCF, SQL Server.
