Entendendo as Fibers do PHP: Programação Assíncrona de Forma Simples

Tradicionalmente, o PHP segue um modelo de execução bastante simples: inicia uma requisição, executa o código de cima para baixo, envia uma resposta e encerra o processo. Essa abordagem tornou a linguagem fácil de aprender e extremamente confiável para aplicações web, mas também significa que operações demoradas — como consultas ao banco de dados, requisições HTTP ou operações de leitura e escrita de arquivos — bloqueiam toda a execução até serem concluídas.

Ao longo dos anos, o ecossistema PHP apresentou diversas abordagens para programação assíncrona. Event loops, callbacks, promises e até generators atuando como corrotinas tornaram possível criar aplicações não bloqueantes, porém quase sempre ao custo de maior complexidade e de um código menos legível. Essas soluções funcionavam, mas exigiam que os frameworks implementassem contornos para limitações da própria linguagem.

O PHP 8.1 introduziu as Fibers, um recurso de baixo nível da linguagem projetado para resolver esse problema de forma elegante. As Fibers não tornam o PHP assíncrono por si só, nem fazem o código executar em paralelo como mágica. Em vez disso, elas fornecem a peça que faltava para que frameworks assíncronos possam suspender e retomar a execução de forma natural, preservando toda a pilha de chamadas.

Hoje, bibliotecas e runtimes modernos como Amp, Revolt e até projetos como FrankenPHP utilizam Fibers para oferecer programação assíncrona com um código que continua parecendo totalmente síncrono. Mesmo que você nunca instancie uma Fiber diretamente, entender seu funcionamento ajudará a compreender melhor o presente e o futuro do desenvolvimento em PHP.

Por que o PHP Precisou das Fibers

Antes da introdução das Fibers, aplicações PHP seguiam um modelo de execução estritamente bloqueante. Sempre que a aplicação realizava uma operação que exigia espera — como ler um arquivo, consultar um banco de dados ou chamar uma API externa — todo o processo ficava parado até que a operação fosse concluída.

Considere o exemplo abaixo:

$user = $database->findUser($id);
$posts = $api->getPosts($user->id);
$image = file_get_contents($avatarUrl);

echo "Done!";

Embora o código pareça simples, cada operação bloqueia a próxima. A requisição para a API só começa quando a consulta ao banco termina, e o download do arquivo só acontece depois que a API responde.

À medida que desenvolvedores passaram a construir aplicações de longa duração, servidores WebSocket e APIs de alta performance, esse modelo de execução tornou-se uma limitação significativa.

As primeiras soluções dependiam fortemente de callbacks:

fetchUser(function ($user) {
    fetchPosts($user, function ($posts) {
        downloadAvatar($posts, function ($avatar) {
            // ...
        });
    });
});

Esse estilo rapidamente se tornou difícil de ler, manter e depurar — um problema conhecido como Callback Hell.

As Promises melhoraram a situação ao tornar o código assíncrono mais composável:

fetchUser()
    ->then(fn ($user) => fetchPosts($user))
    ->then(fn ($posts) => downloadAvatar($posts));

Embora essa abordagem fosse claramente melhor, ela ainda obrigava os desenvolvedores a escreverem código em um estilo diferente daquele utilizado no PHP síncrono tradicional.

Alguns frameworks chegaram a utilizar Generators como corrotinas, devolvendo a execução ao event loop por meio de yield. Apesar de engenhosa, essa técnica utilizava um recurso originalmente criado para iteração, e não para multitarefa cooperativa, tornando sua implementação complexa e, em muitos casos, pouco intuitiva.

As Fibers resolveram esse problema no próprio nível da linguagem. Em vez de obrigar os frameworks a simularem um comportamento assíncrono, o PHP passou a oferecer um mecanismo nativo capaz de pausar a execução e retomá-la posteriormente exatamente do ponto onde ela foi interrompida, sem perder o contexto atual da execução.

Isso permite que código assíncrono tenha praticamente a mesma aparência de um código síncrono comum, tornando aplicações PHP modernas significativamente mais fáceis de escrever, entender e manter.

O que é uma Fiber?

Uma Fiber é um contexto leve de execução que pode ser iniciado, suspenso e retomado manualmente. Diferentemente de uma chamada tradicional de função, uma Fiber pode interromper sua execução em qualquer ponto e continuar posteriormente exatamente de onde parou.

A característica mais importante de uma Fiber é que ela preserva toda a pilha de chamadas (call stack) enquanto está suspensa. Variáveis locais, chamadas de funções aninhadas, estado de objetos e a posição atual da execução permanecem intactos até que a Fiber seja retomada.

Conceitualmente, uma Fiber funciona como um fluxo independente de execução:

Programa Principal
        │
        ├─────────────► Fiber inicia
        │                  │
        │                  ▼
        │          Executa o código
        │                  │
        │                  ▼
        │         Fiber::suspend()
        │                  │
        ◄──────────────────┘
        │
        │   ...outro trabalho...
        │
        ├─────────────► Fiber é retomada
        │                  │
        │                  ▼
        │      Continua exatamente daqui
        │                  │
        │                  ▼
        │          Fiber termina

Isso é fundamentalmente diferente dos Generators, que só podem suspender a execução nos pontos onde existe um yield dentro do próprio generator. Já uma Fiber preserva toda a pilha de execução, tornando-se adequada para implementar corrotinas, event loops e runtimes assíncronos.

Também é importante entender o que as Fibers não são:

• Elas não são threads.
• Elas não executam código em paralelo.
• Elas não tornam funções bloqueantes automaticamente não bloqueantes.

Em vez disso, as Fibers implementam multitarefa cooperativa. Uma Fiber só pausa sua execução quando decide explicitamente se suspender, permitindo que outra Fiber ou o programa principal continue executando.

Essa capacidade aparentemente simples tornou-se a base sobre a qual os frameworks modernos de programação assíncrona em PHP são construídos.

Como as Fibers Funcionam

Uma Fiber possui um ciclo de vida bastante simples. Ela é criada, iniciada, opcionalmente suspensa uma ou mais vezes, retomada sempre que necessário e, por fim, encerra sua execução.

O fluxo pode ser representado da seguinte forma:

Criar Fiber
      │
      ▼
Fiber::start()
      │
      ▼
Executa o código
      │
      ▼
Fiber::suspend()
      │
      ▼
Retorna o controle ao chamador
      │
      ▼
Fiber::resume()
      │
      ▼
Continua exatamente de onde parou
      │
      ▼
Fiber termina

A ideia principal é que chamar Fiber::suspend() não encerra a execução. Em vez disso, a Fiber devolve temporariamente o controle para quem a iniciou.

Quando resume() é chamado posteriormente, o PHP restaura todo o contexto da execução e continua exatamente na instrução seguinte ao Fiber::suspend().

Diferentemente de uma função comum, que sempre executa até retornar um valor ou lançar uma exceção, uma Fiber pode voluntariamente ceder o controle diversas vezes durante sua existência.

É esse mecanismo que permite que frameworks assíncronos executem milhares de tarefas independentes mantendo o código da aplicação limpo, sequencial e fácil de compreender.

Criando sua Primeira Fiber

Criar uma Fiber é surpreendentemente simples. Basta instanciar um objeto Fiber, fornecer o código que ela deverá executar, iniciá-la e retomá-la sempre que sua execução for suspensa.

Veja um exemplo mínimo:

$fiber = new Fiber(function (): void {
    echo "Fiber iniciada\n";

    Fiber::suspend();

    echo "Fiber retomada\n";
});

$fiber->start();

echo "De volta ao programa principal\n";

$fiber->resume();

A saída será:

Fiber iniciada
De volta ao programa principal
Fiber retomada

Vamos entender o que acontece passo a passo:

1. A Fiber é criada, mas ainda não executa nenhum código.
2. A chamada para start() inicia a execução da função.
3. A mensagem "Fiber iniciada" é exibida.
4. Fiber::suspend() pausa a Fiber e devolve imediatamente o controle ao programa principal.
5. O programa principal continua sua execução e imprime "De volta ao programa principal".
6. A chamada para resume() restaura o contexto da Fiber.
7. A execução continua exatamente após Fiber::suspend(), imprimindo "Fiber retomada".

Esse exemplo demonstra o conceito fundamental das Fibers: a execução pode ser pausada e retomada posteriormente sem reiniciar a função nem perder qualquer estado da execução.

Em aplicações reais, frameworks utilizam esse mecanismo para suspender a execução enquanto aguardam respostas de rede, consultas ao banco de dados, temporizadores ou outras operações de entrada e saída (I/O). Assim que a operação é concluída, a Fiber é retomada automaticamente, permitindo que o código continue como se nunca tivesse sido interrompido.

Trocando Valores Entre Fibers

Um dos recursos mais poderosos das Fibers é o suporte à comunicação bidirecional. Uma Fiber pode retornar um valor quando é suspensa, e quem a controla pode enviar outro valor de volta quando ela for retomada.

Isso torna as Fibers muito mais flexíveis do que um simples mecanismo de pausa e continuação, permitindo a troca de informações entre a Fiber e o código que a controla.

Veja um exemplo simples:

$fiber = new Fiber(function (): void {
    $name = Fiber::suspend("Qual é o seu nome?");

    echo "Olá, {$name}!\n";
});

$question = $fiber->start();

echo $question . PHP_EOL;

$fiber->resume("João");

A saída será:

Qual é o seu nome?
Olá, João!

Veja o que acontece:

1. A Fiber inicia sua execução.
2. Fiber::suspend() retorna a string "Qual é o seu nome?" para o chamador e suspende a Fiber.
3. O programa principal recebe esse valor e o imprime.
4. A chamada para resume("João") envia "João" de volta para a Fiber.
5. A expressão Fiber::suspend() passa a valer "João", que é atribuída à variável $name.
6. A Fiber continua sua execução até ser finalizada.

Esse mecanismo de comunicação é amplamente utilizado por runtimes assíncronos. Em vez de trocar apenas strings, os frameworks normalmente suspendem uma Fiber enquanto aguardam uma operação de I/O e a retomam com o resultado dessa operação assim que ela estiver disponível.

Por exemplo, um cliente HTTP pode suspender a Fiber atual enquanto espera a resposta de um servidor remoto. Quando essa resposta chega, o event loop retoma a Fiber e fornece o objeto de resposta, fazendo com que o código pareça completamente síncrono.

Ciclo de Vida de uma Fiber

Uma Fiber passa por um ciclo de vida bem definido, desde sua criação até sua finalização. Compreender esses estados facilita o entendimento de como frameworks assíncronos organizam e executam suas tarefas.

Seu ciclo de vida pode ser representado da seguinte forma:

Criada
    │
    ▼
Iniciada
    │
    ▼
Executando
    │
    ▼
Suspensa
    │
    ▼
Executando
    │
    ▼
Finalizada

O PHP fornece diversos métodos para consultar o estado atual de uma Fiber.

isStarted()

Retorna true depois que a Fiber foi iniciada.

$fiber = new Fiber(fn() => null);

var_dump($fiber->isStarted()); // false

$fiber->start();

var_dump($fiber->isStarted()); // true

isRunning()

Indica se a Fiber está sendo executada naquele momento.

Esse método raramente é necessário em código de aplicação, mas pode ser útil ao implementar escalonadores (schedulers) ou depurar runtimes assíncronos.

isSuspended()

Retorna true quando a Fiber está pausada após uma chamada para Fiber::suspend().

$fiber = new Fiber(function (): void {
    Fiber::suspend();
});

$fiber->start();

var_dump($fiber->isSuspended()); // true

isTerminated()

Retorna true quando a Fiber concluiu sua execução.

$fiber = new Fiber(fn() => print "Done");

$fiber->start();

var_dump($fiber->isTerminated()); // true

Depois que uma Fiber é finalizada, ela não pode mais ser retomada. Qualquer tentativa de chamar resume() nesse estado resultará em uma exceção.

Na prática, a maioria dos desenvolvedores raramente consulta esses estados manualmente. Frameworks como Amp e Revolt gerenciam todo o ciclo de vida das Fibers internamente, expondo uma API assíncrona muito mais simples para o código da aplicação.

Fibers vs Generators

Como muitas bibliotecas assíncronas em PHP utilizavam Generators antes do PHP 8.1, é comum confundir esses dois recursos. Embora ambos permitam pausar a execução e retomá-la posteriormente, eles foram projetados para resolver problemas completamente diferentes.

Os Generators foram introduzidos para facilitar a iteração sobre grandes volumes de dados sem a necessidade de carregar tudo na memória. Seu principal objetivo é a avaliação preguiçosa (lazy evaluation), e não concorrência.

As Fibers, por outro lado, foram criadas especificamente para implementar multitarefa cooperativa.

As diferenças ficam mais claras na tabela abaixo:

Considere um Generator:

function numbers(): Generator
{
    yield 1;
    yield 2;
    yield 3;
}

A execução só pode ser interrompida nos pontos onde existe um yield, e apenas dentro do próprio Generator.

Uma Fiber funciona de maneira completamente diferente:

$fiber = new Fiber(function (): void {
    firstFunction();
    secondFunction();
    thirdFunction();

    Fiber::suspend();

    fourthFunction();
});

Nesse caso, a Fiber suspende todo o contexto de execução, independentemente de quantas chamadas de funções estejam ativas naquele momento. Quando ela é retomada, o PHP restaura toda a pilha de chamadas exatamente como ela estava antes da suspensão.

Foi justamente essa capacidade que tornou os frameworks modernos de programação assíncrona muito mais simples após o lançamento do PHP 8.1. Antes das Fibers, as bibliotecas precisavam construir abstrações bastante complexas sobre os Generators para simular um comportamento que agora é fornecido nativamente pela linguagem.

Fibers vs Threads

Talvez o maior equívoco sobre Fibers seja acreditar que elas são uma espécie de thread leve.

Elas não são.

Embora ambas possam melhorar a capacidade de resposta de uma aplicação, elas resolvem problemas completamente diferentes.

As threads utilizam multitarefa preemptiva. O sistema operacional decide quando cada thread será interrompida para que outra possa executar. Isso traz desafios como condições de corrida (race conditions), deadlocks e a necessidade de mecanismos de sincronização, como mutexes e locks.

As Fibers, por sua vez, utilizam multitarefa cooperativa.

Uma Fiber continua executando até decidir explicitamente suspender sua própria execução:

Fiber::suspend();

Nesse momento, outra Fiber ou o programa principal pode assumir o controle da execução.

Como apenas uma Fiber é executada por vez, não existe acesso simultâneo à memória compartilhada. Isso elimina toda uma categoria de problemas de concorrência bastante comuns em aplicações multithread.

É importante destacar, porém, que as Fibers não oferecem paralelismo.

Se sua aplicação precisa aproveitar vários núcleos da CPU para executar tarefas intensivas de processamento, tecnologias como múltiplos processos PHP, process pools ou a extensão parallel são alternativas mais adequadas.

O verdadeiro ponto forte das Fibers é outro: permitir o tratamento eficiente de grandes quantidades de operações de I/O, como requisições HTTP, consultas ao banco de dados, conexões WebSocket e acesso a arquivos, mantendo o código simples, legível e fácil de manter.

Como Frameworks Assíncronos Utilizam Fibers

Embora o PHP disponibilize diretamente a classe Fiber, a maioria dos desenvolvedores jamais precisará criar uma Fiber manualmente. Na prática, elas funcionam como um componente de baixo nível utilizado por frameworks e runtimes assíncronos.

Bibliotecas como Amp e Revolt utilizam Fibers para esconder toda a complexidade da programação assíncrona por trás de uma API que parece completamente síncrona.

Imagine uma aplicação que precise realizar diversas operações de I/O:

• Consultar um banco de dados.
• Chamar uma API REST externa.
• Ler dados do Redis.
• Escrever informações em um arquivo de log.

Em uma aplicação tradicional, cada operação bloqueia a próxima. Já em um runtime assíncrono, sempre que uma dessas operações precisa aguardar uma resposta, a Fiber atual é suspensa, permitindo que outras Fibers continuem executando enquanto o resultado não chega.

Do ponto de vista do desenvolvedor, o código continua limpo e sequencial:

$user = $database->find($id);

$posts = $api->getPosts($user->id);

$avatar = $storage->download($user->avatar);

return [
    'user' => $user,
    'posts' => $posts,
    'avatar' => $avatar,
];

Não há callbacks, cadeias de Promises nem máquinas de estado explícitas. Nos bastidores, o runtime suspende e retoma automaticamente as Fibers sempre que encontra uma operação assíncrona.

Essa é uma das maiores vantagens das Fibers: elas fazem com que a programação assíncrona tenha praticamente a mesma aparência do PHP tradicional.

Também vale destacar que as Fibers representam apenas uma parte da solução. Elas trabalham em conjunto com um event loop, responsável por monitorar sockets, temporizadores, descritores de arquivos e outros eventos assíncronos. Enquanto o event loop decide quando uma Fiber deve continuar sua execução, a Fiber preserva de onde ela deverá continuar.

Juntos, esses dois componentes tornam possível a criação de runtimes PHP modernos capazes de lidar com milhares de conexões simultâneas sem abrir mão de um código limpo, legível e de fácil manutenção.

Exemplo no Mundo Real

Imagine que você está desenvolvendo um endpoint de uma API responsável por retornar o perfil de um usuário.

Para gerar a resposta, sua aplicação precisa:

1. Buscar o usuário no banco de dados.
2. Obter as publicações recentes em outro serviço.
3. Recuperar o avatar em um armazenamento de objetos.
4. Ler as preferências armazenadas no Redis.

Uma aplicação PHP tradicional executaria essas operações de forma sequencial:

Banco de Dados
      │
      ▼
API Externa
      │
      ▼
Object Storage
      │
      ▼
Redis
      │
      ▼
Resposta

Cada etapa aguarda a conclusão da anterior, aumentando o tempo total de resposta.

Um runtime assíncrono trabalha de maneira diferente. Sempre que uma operação precisa aguardar uma resposta de I/O, a Fiber atual é suspensa para que outras tarefas possam continuar sendo executadas.

Conceitualmente, a execução acontece da seguinte forma:

Fiber A → Banco de Dados (aguardando...)
              │
              ▼
Fiber B → API HTTP
              │
              ▼
Fiber C → Redis
              │
              ▼
Fiber A é retomada
              │
              ▼
Gera a resposta

Mesmo que diversas tarefas avancem simultaneamente durante a mesma requisição, o código da aplicação continua parecendo um PHP síncrono comum:

$user = $database->find($id);

$posts = $api->recentPosts($user->id);

$preferences = $redis->get("preferences:{$user->id}");

return new UserProfile(
    $user,
    $posts,
    $preferences
);

Não é necessário suspender ou retomar Fibers manualmente. O runtime assíncrono faz isso automaticamente, permitindo que você se concentre na lógica de negócio em vez do fluxo de execução.

É justamente por isso que as Fibers se tornaram uma adição tão importante ao PHP: elas permitem construir aplicações altamente concorrentes sem abrir mão de um código limpo e fácil de compreender.

Erros Comuns

Embora o conceito de Fiber seja relativamente simples, alguns equívocos aparecem com bastante frequência entre desenvolvedores que estão começando a estudar programação assíncrona em PHP.

Acreditar que Fibers são Threads

Esse é, de longe, o erro mais comum.

As Fibers não executam simultaneamente e não utilizam múltiplos núcleos da CPU. Elas implementam multitarefa cooperativa, e não execução paralela.

Esperar melhorias automáticas de desempenho

Simplesmente colocar um trecho de código dentro de uma Fiber não fará sua aplicação ficar mais rápida.

Se o código continuar utilizando APIs bloqueantes tradicionais, ele continuará bloqueando a execução. As Fibers só demonstram seu verdadeiro potencial quando combinadas com bibliotecas assíncronas capazes de suspender a execução em vez de bloquear o processo.

Criar Fibers para tudo

Só porque você pode criar Fibers manualmente não significa que deva fazer isso.

Na maioria das aplicações, é preferível deixar que frameworks e runtimes gerenciem automaticamente a criação, o agendamento e todo o ciclo de vida das Fibers.

Esquecer de retomar uma Fiber suspensa

Depois que uma Fiber executa Fiber::suspend(), ela permanece pausada indefinidamente até que alguém chame resume().

Uma Fiber suspensa que nunca é retomada jamais concluirá sua execução.

Ignorar exceções

Exceções lançadas dentro de uma Fiber não desaparecem.

Caso não sejam tratadas dentro da própria Fiber, elas serão propagadas para quem a retomou.

Em outras palavras, o tratamento de erros continua funcionando exatamente como no PHP síncrono tradicional.

Pensar que Fibers substituem bibliotecas assíncronas

Fibers são um recurso da linguagem, e não um framework de programação assíncrona.

Elas fornecem o modelo de execução, mas ainda é necessário utilizar um event loop e bibliotecas não bloqueantes para construir aplicações realmente escaláveis.

Boas Práticas

Embora Fibers sejam um recurso de baixo nível, algumas recomendações ajudam a criar aplicações assíncronas mais limpas e fáceis de manter.

Deixe os frameworks gerenciarem as Fibers

Na maioria dos projetos, você nunca precisará instanciar uma Fiber diretamente.

Frameworks como Amp e Revolt já oferecem abstrações de nível mais alto responsáveis pelo agendamento das tarefas, cancelamento, propagação de exceções e gerenciamento de recursos.

Escreva código como se fosse síncrono

Uma das maiores vantagens das Fibers é a legibilidade.

Em vez de reorganizar sua aplicação em torno de callbacks ou cadeias de Promises, mantenha sua lógica de negócio simples, linear e sequencial sempre que possível.

Utilize bibliotecas assíncronas de forma consistente

Misturar APIs bloqueantes e não bloqueantes normalmente elimina boa parte dos benefícios oferecidos pelas Fibers.

Se sua aplicação utiliza um runtime assíncrono, prefira bibliotecas projetadas especificamente para esse ambiente.

Mantenha cada Fiber focada em uma única responsabilidade

Uma Fiber deve representar uma unidade lógica de trabalho.

Evite colocar responsabilidades não relacionadas dentro da mesma Fiber, pois isso dificulta a manutenção e a depuração da aplicação.

Trate exceções normalmente

Como as Fibers preservam toda a pilha de chamadas, as exceções continuam previsíveis.

Sempre que necessário, utilize blocos try/catch exatamente como faria em uma aplicação PHP tradicional.

Entenda que Fibers são infraestrutura

Talvez a recomendação mais importante seja compreender o verdadeiro papel das Fibers dentro do ecossistema PHP.

Elas não foram criadas para substituir a forma tradicional de programar em PHP. Seu objetivo é fornecer o mecanismo de baixo nível que permite a construção de runtimes assíncronos modernos.

Na prática, a maioria dos desenvolvedores se beneficiará muito mais entendendo como as Fibers funcionam do que criando Fibers manualmente. Esse conhecimento costuma ser um diferencial entre quem apenas utiliza frameworks assíncronos e quem realmente compreende seu funcionamento interno.

Perguntas Frequentes

As Fibers estão disponíveis em todas as versões do PHP?

Não.

As Fibers foram introduzidas no PHP 8.1. Se sua aplicação utiliza PHP 8.0 ou versões anteriores, a classe Fiber não está disponível.

As Fibers tornam o PHP assíncrono?

Sozinhas, não.

As Fibers fornecem a capacidade de pausar e retomar a execução, mas não tornam automaticamente operações bloqueantes em operações assíncronas. Para isso, elas precisam trabalhar em conjunto com um event loop e bibliotecas não bloqueantes.

As Fibers tornam o PHP mais rápido?

Nem sempre.

Fibers não são um mecanismo de otimização para tarefas intensivas de processamento.

Seu principal benefício é melhorar a concorrência, permitindo que aplicações tratem um grande número de operações de I/O de forma mais eficiente, sem bloquear todo o processo.

Para scripts comuns e aplicações PHP tradicionais, normalmente elas oferecem pouca ou nenhuma melhoria de desempenho.

As Fibers executam código em paralelo?

Não.

Dentro de um processo PHP, apenas uma Fiber é executada por vez. A troca de contexto acontece apenas quando uma Fiber decide suspender voluntariamente sua própria execução.

Se você precisa de paralelismo real utilizando múltiplos núcleos da CPU, será necessário recorrer a múltiplos processos ou tecnologias como a extensão parallel.

Devo criar Fibers manualmente?

Na maioria dos casos, não.

A menos que você esteja desenvolvendo um framework assíncrono, um event loop ou outra biblioteca de baixo nível, o ideal é deixar que ferramentas como Amp ou Revolt gerenciem as Fibers automaticamente.

A maioria dos desenvolvedores utilizará Fibers de forma indireta, sem jamais instanciar a classe Fiber.

As Fibers substituem Threads?

Não.

Fibers e Threads resolvem problemas diferentes.

Threads oferecem paralelismo, permitindo que múltiplas tarefas sejam executadas simultaneamente em diferentes núcleos da CPU.

Fibers oferecem concorrência cooperativa, permitindo que tarefas suspendam e retomem sua execução de maneira eficiente dentro de uma única thread.

Em aplicações de alto desempenho, ambas as abordagens podem coexistir quando necessário.

Laravel e Symfony utilizam Fibers?

Os frameworks em si não dependem de Fibers durante seu ciclo tradicional de requisição e resposta.

No entanto, o ecossistema PHP utiliza cada vez mais Fibers em componentes assíncronos, servidores de aplicação e runtimes que podem ser integrados a esses frameworks. À medida que a programação assíncrona evolui no PHP, as Fibers tornam-se uma parte cada vez mais importante dessa infraestrutura.

As Fibers substituem as Promises?

Não exatamente.

Promises e Fibers resolvem problemas diferentes e, frequentemente, trabalham juntas.

As Promises representam o resultado futuro de uma operação assíncrona, enquanto as Fibers fornecem o modelo de execução que permite escrever código assíncrono de forma natural e sequencial. Muitos frameworks modernos utilizam ambas internamente para oferecer APIs limpas e intuitivas.

Conclusão

Durante muitos anos, a programação assíncrona em PHP dependeu de abstrações complexas construídas sobre callbacks, Promises ou até mesmo Generators utilizados como corrotinas. Embora essas soluções funcionassem, elas frequentemente tornavam o código mais difícil de ler, manter e depurar.

As Fibers mudaram esse cenário.

Em vez de introduzir mais um framework assíncrono, o PHP 8.1 adicionou um recurso fundamental à linguagem que permite suspender e retomar a execução preservando toda a pilha de chamadas. Essa capacidade, aparentemente simples, tornou-se a peça que faltava para os runtimes assíncronos modernos.

Hoje, bibliotecas como Amp e Revolt utilizam Fibers para fazer com que a programação assíncrona seja praticamente indistinguível do PHP síncrono tradicional. O desenvolvedor escreve um código limpo e linear, enquanto o runtime gerencia automaticamente o escalonamento das tarefas, o event loop e as operações de I/O não bloqueantes nos bastidores.

Mesmo que você nunca crie uma Fiber manualmente, compreender seu funcionamento proporciona uma visão muito mais profunda da arquitetura moderna do PHP. Esse conhecimento ajuda a entender como servidores de alto desempenho, clientes HTTP assíncronos, aplicações WebSocket e diversos outros sistemas concorrentes conseguem funcionar utilizando uma sintaxe familiar.

À medida que a linguagem continua evoluindo, tudo indica que as Fibers permanecerão como uma das adições mais importantes ao modelo de execução do PHP. Não porque mudem a forma como escrevemos código no dia a dia, mas porque tornam possível toda uma nova geração de ferramentas, bibliotecas e frameworks.

Se o seu objetivo é evoluir como desenvolvedor PHP — especialmente em cargos de nível sênior — entender as Fibers é um investimento que certamente vale a pena. Elas deixaram de ser apenas um recurso avançado da linguagem e passaram a fazer parte dos alicerces do PHP moderno.