DEV Community: Guilherme R.

Event Loop: como o JavaScript executa código assíncrono

Guilherme R. — Sat, 23 May 2026 03:23:16 +0000

O JavaScript é uma linguagem single thread, ou seja, possui apenas uma thread de execução e por isso depende de um mecanismo chamado Event Loop para coordenar a execução de operações assíncronas. Algumas realizadas em paralelo por recursos externos como Web APIs, outras simplesmente adiadas para depois que o código síncrono atual terminar.

Para entender como o Event loop funciona vamos entender rapidamente as seguintes estruturas utilizadas pelo JS:

Call Stack
Web APIs
Task queue
Microtask queue
Event loop

Call Stack

É a estrutura de dados que segue o princípio LIFO (Last in, First out) utilizada na memória para organizar e processar a execução do código. Sempre que invocamos uma função utilizando (), como por exemplo firstFn(), ela é empilhada na call stack. Caso a firstFn invoque uma outra função secondFn(), essa última será empilhada em cima da firstFn e será executada e removida primeiro, seguindo o princípio LIFO.

Importante frisar que qualquer código que não foi declarado dentro de uma função também será empilhado na call stack, pois no momento que um arquivo JS é lido, o motor JS cria o Global Execution Context (Contexto de Execução Global), sendo a primeira coisa a ser empilhada na Call stack.

Web APIs

O JavaScript é uma linguagem de programação e sabe apenas processar dados e lógica. Não sabe o que é um clique no mouse, rede, timer…, quem é reponsável por lidar com isso é o browser, que tem acesso a rede, tela, microfone e demais recursos.

As Web APIs são a ponte, ou seja, um conjunto de funcionalidades que o browser disponibiliza para o código JS utilizar. Com isso, qualquer processo que é executado por meio das Web APIs é um trabalho externo ao JS, sendo realizado em uma thread separada, fora da thread do JavaScript.

Web APIs é utilizada no contexto onde o JavaScript está rodando no navegador. Quando o JS é utilizado no Node.js o equivalente a Web APIs é a libuv, uma biblioteca desenvolvida em C para possibilitar input e output assíncronos.

Diferente da Web APIs, o Node.js possui a nextTick Queue, uma fila exclusiva com prioridade ainda maior que a Microtask Queue, gerenciada pelo próprio runtime do Node.js.

Task Queue

Estrutura de dados Fila que segue o princípio FIFO (First in, First out) utilizado como memória para receber todos os callbacks que vieram dos processamentos realizados externamente pela Web APIs. Com isso, se utilizarmos recursos do browser através das Web APIs, quando o processamento for finalizado, o callback virá para a Task Queue para ser enviada pelo Event Loop a Call Stack assim que a mesma estiver vazia.

Task Queue também pode ser encontrada como Macrotask Queue ou Callback Queue, todas se referem a mesma estrutura.

Confira algumas das Web APIs:

fetch()
setTimeout()
setInterval()
addEventListener()

Microtask Queue

Estrutura exatamente igual a Callback Queue, diferindo em apenas dois pontos em como é utilizada e consumida pelo Event Loop:

A Microtask existe para receber callbacks cujo resultado já está disponível dentro do próprio motor JS, sem necessidade de processamento externo. Não há trabalho sendo feito, apenas a execução do callback é inserida na fila, sendo adiado pra depois que o código síncrono atual terminar;
Essa queue tem uma prioridade maior comparada a Callback queue. O Event loop sempre esvazia totalmente a Microtask Queue antes de pegar um item da Callback Queue. Após mover um item da Callback Queue para a Call Stack o Event Loop volta a verificar a Microtask Queue primeiro, mantendo a prioridade.

A Microtask Queue também pode ser encontrada como Job Queue

Confira alguma das formas de fazer um processamento assíncrono, enviando para a Microtask queue para ser resolvido depois:

Promise.then()
Promise.catch()
Promise.finally()
async/await
queueMicrotask()

Event Loop

O Event Loop é um loop infinito que coordena a Call Stack, Microtask Queue e Callback Queue. Sempre que a Call Stack está vazia ele move o próximo callback para ela na ordem correta: esvazia toda a Microtask Queue primeiro para então poder pegar um callback da Callback Queue e recomeçar todo esse fluxo novamente.

O Fluxo completo

Para entendermos como todo o fluxo funciona para possibilitar que uma linguagem single thread consiga fazer um processamento em paralelo com a Web APIs ou adiar uma execução, vamos conferir o seguinte código:

function soma(a, b) {
    return a + b;
}

console.log('Síncrono 1');

console.log(soma(5, 5));

setTimeout(() => {
    console.log("Assíncrono 2")
}, 0);

Promise.resolve("Assíncrono 1").then((item) => {
    console.log(item)
});

console.log('Síncrono 2')

Confira a ordem como a Call Stack será empilhada:

No momento que esse código for lido, será criado o Global Execution Context, contendo o todo, sendo empilhado na base da Call Stack;
O console.log(’Síncrono 1’) será empilhado, executado e removido da pilha;
O console.log() que possui a soma(5, 5) será empilhado. O soma(5, 5) será empilhado em seguida, executado e removido. Com isso, o console.log(10) será executado e removido da pilha;
O setTimeout(callback, 0) é empilhado, registra o callback na Web API e é removido;
1. O processamento ocorre na thread da Web API paralelamente enquanto o fluxo continua em andamento. Quando finalizado, o callback é enviado para a Task Queue que só será verificado pelo Event Loop após a Microtask Queue estar completamente vazia
O Promise.resolve(”Assíncrono 1”) é empilhado, registra o callback na Microtask Queue e é removido;
O console.log(’Síncrono 2’) é empilhado, executado e removido da pilha;
Agora que todo o documento foi lido, o Global Execution Context é finalmente removido da pilha;
Com a Call Stack vazia o Event Loop passa a esvaziar a Microtask Queue, movendo o primeiro callback para a Call Stack, executando o console.log('Assíncrono 1') e removendo-o da pilha
Com a Call Stack e a Microtask Queue vazia o Event Loop move o primeiro item da Task Queue: console.log(’Assíncrono 2’), sendo executado e removido da pilha.

Perceba que, mesmo que o setTimeout ocorra antes do Promise.resolve, como ele é inserido na Task Queue após o timer expirar na Web API, ele acaba sendo executado somente após a Promise.resolve, pelo fato do Event Loop dar prioridade a Microtask Queue.

Nosso fluxo termina aqui, mas caso a Microtask Queue tivesse um novo callback registrado, o Event Loop iria priorizar movê-lo para a Call Stack antes de checar a Task Queue novamente.

Referências

Créditos de imagem

Foto de Aleksandr Popov na Unsplash

Guia de Estrutura de Dados: Implementando Filas de alta performance em JavaScript

Guilherme R. — Wed, 21 Jan 2026 10:31:27 +0000

Introdução

A estrutura de dados Fila (Queue) é uma das mais fundamentais da computação e embora seja de fato uma estrutura simples, possui uma grande capacidade de organizar o fluxo de dados. No entanto, a escolha de como implementar uma fila pode ser a diferença entre um sistema fluido e um gargalo de performance. No decorrer deste guia, vamos entender seu conceito, por que ela é essencial para a escalabilidade e como implementá-la de forma performática.

O Conceito FIFO

Diferentemente da estrutura de dados Pilha, que segue o princípio LIFO (Last-In, First-Out), a Fila segue o princípio FIFO (First-In, First-Out). Na prática, seu funcionamento remete exatamente à fila que conhecemos no dia a dia: o primeiro que entra deve ser o primeiro a sair.

Para que esse princípio seja respeitado, utilizamos duas operações fundamentais que ocorrem nas extremidades da estrutura:

Enqueue: Adiciona um novo elemento no final da fila.
Dequeue: Remove o elemento que está no início da fila.

Array x Objeto

Para utilizar essa estrutura em nossos projetos podemos seguir por dois caminhos: array ou objeto.

Quando utilizamos array temos a vantagem de possuir propriedades e métodos nativos. No JavaScript, por exemplo, temos o push(), shift(), além de funções extremamente úteis como map(), filter() e reduce(). Com isso não temos o custo de criar toda a lógica do zero.

Para contextos com poucos dados, o array nos atende perfeitamente. No entanto, em cenários de processamento massivo, essa abordagem torna-se um gargalo. Isso ocorre porque a maioria dos métodos de array possui uma complexidade de tempo linear O(n). Isso significa que, à medida que a fila cresce o tempo de execução cresce na mesma proporção. Mas por que isso ocorre especificamente na operação de remoção?

O custo do shift e a reindexação

Quando realizamos uma operação de remoção (dequeue), além de apenas remover o elemento, o JavaScript precisa manter a integridade da estrutura, movendo todos os itens restantes para uma posição anterior.

Dessa forma, ao remover o primeiro item de um array de 1.000 itens, aquele que estava no índice 1 precisa ir para o 0, o que estava no 2 para o 1 e assim sucessivamente. Ou seja, serão necessárias 999 operações de reindexação apenas para essa primeira remoção. Esse procedimento é feito de maneira “invisível” pelo método shift() do JavaScript, mas o custo está lá, consumindo processamento.

Memória contígua e Array esparsos

O processo de reindexação é necessário porque, por padrão, o JavaScript tenta alocar arrays em um bloco de memória contíguo. Isso significa que o endereço de memória de um elemento está imediatamente após o endereço do elemento anterior. Essa organização é o que permite que o acesso a qualquer índice seja instantâneo.

Para que o acesso continue ocorrendo de forma eficiente, a reindexação evita a criação de um Sparse Array (Array Esparso). Esse tipo de array possui índices vazios, o que faz com que o motor do JavaScript trate o bloco de memória como um objeto comum, perdendo a capacidade de prever onde o próximo dado está guardado, causando uma perda na performance.

Otimizando com objeto

Agora que entendemos as limitações do array quando aplicado a uma fila, vamos entender como criar uma fila baseada em objeto, com o objetivo de atingir uma melhor performance, garantindo uma complexidade de tempo constante O(1) nas operações de enqueue e dequeue.

Implementação com JavaScript

class Queue {
    #count;
    #lowestCount;
    #items;

    constructor() {
        this.#count = 0;
        this.#lowestCount = 0;
        this.#items = {};
    }

    // Adiciona um novo elemento no final da fila
    enqueue(element) {
        this.#items[this.#count] = element;
        this.#count++;
    }

    // Remove e retorna o primeiro elemento da fila
    dequeue() {
        if (this.isEmpty())
            return undefined;

        const result = this.#items[this.#lowestCount];
        delete this.#items[this.#lowestCount];
        this.#lowestCount++;

        return result;
    }

    // Retorna o primeiro elemento da fila
    peek() {
        if (this.isEmpty())
            return undefined;

        return this.#items[this.#lowestCount];
    }

    // Retorna se a fila está vazia ou não
    isEmpty() {
        return this.size() === 0;
    }

    // Retorna a quantidade de elementos na fila
    size() {
        return this.#count - this.#lowestCount;
    }

    // Limpa a fila
    clear() {
        this.#items = {};
        this.#count = 0;
        this.#lowestCount = 0;
    }
}

Implementação com TypeScript

class Queue<T> {
    private count: number;
    private lowestCount: number;
    private items: Record<number, T>;

    constructor() {
        this.count = 0;
        this.lowestCount = 0;
        this.items = {}
    }

    // Adiciona um novo elemento no final da fila
    enqueue(element: T): void {
        this.items[this.count] = element;
        this.count++;
    }

    // Remove e retorna o primeiro elemento da fila
    dequeue(): T | undefined {
        if (this.isEmpty())
            return undefined;

        const result = this.items[this.lowestCount];
        delete this.items[this.lowestCount];
        this.lowestCount++;

        return result;
    }

    // Retorna o primeiro elemento da fila
    peek(): T | undefined {
        if (this.isEmpty())
            return undefined;

        return this.items[this.lowestCount];
    }

    // Retorna se a fila está vazia ou não
    isEmpty(): boolean {
        return this.size() === 0;
    }

    // Retorna a quantidade de elementos na fila
    size(): number {
        return this.count - this.lowestCount;
    }

    // Limpa a fila
    clear(): void {
        this.count = 0;
        this.lowestCount = 0;
        this.items = {};
    }
}

Observe que ao utilizarmos o Queue<T>, o TypeScript fará a inferência automática. Ou seja, se criarmos uma new Queue(), o método peek() saberá que o retorno é uma string ou undefined, fornecendo o autocomplete corretamente no editor.

Quando não usar

Mais importante do que dominar uma estrutura é saber quando utilizá-la. Pois na programação dificilmente existirá uma solução absoluta, toda escolha deve ser baseada em trade-offs. Em cenários de filas pequenas, o array torna o código mais conciso, fácil de manter, além de provavelmente entregar um desempenho melhor.

O desempenho melhor nesses cenários ocorre porque motores modernos, como o V8 tratam os arrays de uma maneira especial. Eles são armazenados internamente em uma estrutura chamada Elements Store, separada das demais propriedades de objeto para fins de otimização. Quando esses arrays não possuem buracos, eles são classificados como Fast Elements e organizados em categorias como:

PACKED_SMI_ELEMENTS: Para inteiros pequenos. É o nível de performance mais alto.
PACKED_DOUBLE_ELEMENTS: Para valores de ponto flutuantes ou inteiros que não pertencem a SMI.
PACKED_ELEMENTS: Para valores que não encaixam nas categorias acima, como strings e objetos.

Por conta dessa otimização de baixo nível, o custo de instanciar uma classe e gerenciar a remoção de propriedades com delete pode ser maior do que a reindexação de um array pequeno.

Trade-offs: Quando a complexidade vale a pena

Pequena Escala (Arrays): Quando a quantidade de itens na Fila é relativamente pequena, os testes mostram que o array possui uma maior performance. Deixando claro que o custo da reindexação é compensado pelas otimizações de Fast Elements do V8. Neste cenário, o que devemos priorizar é a simplicidade do código.

Alta Carga (Objetos): Aqui o cenário muda drasticamente. Uma fila grande é impactada significativamente pela reindexação, mesmo com a otimização do motor V8, pois o custo acumulativo nesses cenários não é sustentável em larga escala.

Cenário de testes com numbers:

Itens	Fila com Array	Fila com Objeto
1.000	0.079ms	0.215ms
10.000	1.377ms	0.794ms
100.000	3.574.7ms (3.5s)	8.9ms
200.000	28.541.7ms (28.5s)	9.38ms

Conforme a Fila aumenta, torna-se cada vez mais nítida a diferença de performance, ficando claro a vantagem do uso do objeto em cenários de alta carga.

Confira o código utilizado para obter os valores dos testes realizados em ambiente Node:

// Testa a performance da fila utilizando array
function testArrayPerformance(size) {
    const queue = [];

    for (let i = 0; i < size; i++)
        queue.push(i);

    const start = performance.now();

    for (let i = 0; i < size; i++)
        queue.shift();

    const end = performance.now();

    const performanceResult = end - start;
    return performanceResult;
}

// Testa a performance da fila utilizando objeto
function testObjectPerformance(size) {
    const queue = new Queue();

    for (let i = 0; i < size; i++)
        queue.enqueue(i);

    const start = performance.now();

    for (let i = 0; i < size; i++)
        queue.dequeue();

    const end = performance.now();

    const performanceResult = end - start;
    return performanceResult;
}

// Exibe a média da performance de 5 execuções por padrão
function runBenchmark(label, fn, iterations = 5) {
    const results = [];

    for (let i = 0; i < iterations; i++) {
        results.push(fn());
    }

    const average = results.reduce((a, b) => a + b) / iterations;
    console.log(`${label} - Média de ${iterations} execuções: ${average.toFixed(4)}ms`);
}

// Define a quantidade de itens da fila
const size = 100000;

runBenchmark("Array Queue (shift)", () => testArrayPerformance(size));
runBenchmark("Object Queue (dequeue)", () => testObjectPerformance(size));

Conclusão

Com as implementações apresentadas, mostramos como podemos resolver o gargalo de performance, mas além disso, evidenciamos quando devemos ou não nos preocupar com isso.

Espero que tenha ficado claro não apenas como criar uma fila, mas o porquê de cada escolha técnica por trás dela. Procurar entender o que realmente acontece “debaixo do capô” é um dos fatores que nos diferenciam como programadores.

Referências

GRONER, Loiane. Estruturas de Dados e Algoritmos com JavaScript. 2ª Edição. Novatec Editora Ltda. Fevereiro/2019.

BYNENS, Mathias. Elements kinds in V8. V8 Dev Blog, 2017. Disponível em: https://v8.dev/blog/elements-kinds

BRUNI, Camillo. Fast properties. V8 Dev Blog, 2017. Disponível em: https://v8.dev/blog/fast-properties

Créditos de imagem

Foto de Meizhi Lang na Unsplash