Introduction

Callbacks and threads are related concepts in concurrent programming, but they are not the same thing. A callback is a control-flow technique: one piece of code gives another piece of code a function to call later. A thread is an execution mechanism: a separate flow of execution managed by the runtime or operating system.

A callback may run on the same thread, on a background thread, or on an event loop with no extra thread creation at all. That is why asking “do callbacks use threads?” has no single universal answer.

What a Callback Is

A callback is just a function provided to another function or system so it can be invoked later.

1function doWork(callback) {
2  const result = 42;
3  callback(result);
4}
5
6doWork(value => console.log(value));

The callback here is the function passed into doWork.

Nothing about this example requires a separate thread. The callback can run immediately on the same call stack.

What a Thread Is

A thread is a unit of execution. Multiple threads can run concurrently depending on the language runtime and operating system.

In Java, for example:

new Thread(() -> System.out.println("running in another thread")).start();

That code creates a new thread, but it does not automatically imply callbacks. Threads and callbacks can appear together, but they solve different problems.

How They Interact

Callbacks are often used to notify code when async work finishes. Threads are one possible way that async work can happen.

Examples:

• JavaScript browser callbacks usually run on the event loop, not on extra threads you manage directly.
• Java executor callbacks may run on worker threads.
• UI frameworks often require callbacks that update the screen to run on the main thread.

So the correct question is often: on which thread does this callback execute?

Same Callback Pattern, Different Execution Models

Two systems can expose similar callback APIs while using very different runtime behavior.

A network library might:

• perform I/O on a worker thread and invoke your callback there
• perform I/O asynchronously and post your callback back to the UI thread
• use an event loop and invoke your callback when the socket becomes ready

The callback abstraction stays the same while the threading model changes underneath.

Why This Matters

The threading context of a callback affects:

• thread safety
• UI updates
• locking needs
• race conditions
• performance assumptions

If a callback runs on a background thread, touching UI objects directly may be illegal. If it runs on the main thread, long work inside the callback may freeze the interface.

That is why callback documentation should always be read together with execution-context documentation.

A Practical Mental Model

Think of callbacks as “what code should run later?” and threads as “where and how does that code run?”

Those are separate design questions.

That model helps avoid confusion such as:

• assuming async always means multithreaded
• assuming callbacks are inherently parallel
• assuming a callback can safely touch shared state without synchronization

Common Pitfalls

A common mistake is assuming that because a callback happens later, it must be running on another thread. Event-loop systems prove that is not always true.

Another mistake is ignoring thread context when writing callback bodies. Whether a callback runs on a UI thread or a worker thread changes what code is safe inside it.

Developers also sometimes block inside a callback without realizing they are blocking the main thread or a scarce worker thread.

Finally, callbacks and threads are only part of the story. Futures, promises, coroutines, and async-await often wrap the same underlying ideas in more structured forms.

Summary

• A callback is a function to be invoked later.
• A thread is a unit of execution.
• Callbacks may run on the same thread, a worker thread, or an event loop.
• The important practical question is which thread executes the callback.
• Understanding both the callback API and the execution context is essential for correct concurrent code.