Do silício ao processo

Situação concreta: onde está o programa quando ele “está rodando”?

Você clica em “Consultar ordem 1842”. A tela gira por dez segundos e mostra “arquivo não encontrado”. Alguém diz que “o servidor está lento”; outra pessoa recomenda aumentar memória; uma terceira reinicia tudo. Essas ações podem apagar evidências sem tocar na causa. O erro pode estar no caminho do arquivo, numa espera de rede, numa permissão, num disco cheio ou num cálculo que não termina.

Para investigar, precisamos acompanhar a execução por camadas. Um arquivo com código não trabalha sozinho. Um runtime o lê ou um compilador o transforma; o sistema operacional cria um processo; a unidade central de processamento executa instruções; memória mantém o estado temporário; arquivos ou bancos persistem dados; rede conecta serviços. O modelo deste capítulo não forma um engenheiro de hardware, mas permite fazer perguntas melhores e coletar a primeira evidência.

Pré-requisitos e objetivos

Você deve saber distinguir problema e solução e conseguir executar um comando no terminal. Não é necessário conhecer eletrônica. Ao final, deverá desenhar o caminho do código à execução, explicar o que sobrevive a um reinício, distinguir processo e thread e diagnosticar um caminho relativo incorreto.

Vocabulário essencial

• Bit representa dois estados, geralmente escritos 0 e 1; byte é normalmente um grupo de oito bits.
• Unidade central de processamento (CPU) executa instruções e operações sobre dados.
• Registrador é uma pequena posição de trabalho dentro da CPU.
• Cache guarda cópias de dados usados recentemente perto da CPU.
• Memória de acesso aleatório (RAM) mantém bytes acessíveis rapidamente enquanto há energia.
• Armazenamento, como SSD, preserva dados após desligamento.
• Sistema operacional (SO) administra hardware e oferece abstrações aos programas.
• Kernel é o núcleo privilegiado do SO, responsável por recursos e proteção.
• Programa é código e dados armazenados; processo é uma instância desse programa em execução.
• PID, process identifier, é o número que identifica um processo naquele sistema e momento.
• Thread é um fluxo de execução dentro de um processo.
• Runtime é a camada que sustenta uma linguagem ou aplicação, como o interpretador Python ou a máquina virtual Java.
• Arquivo é uma sequência persistente de bytes acompanhada por metadados.
• Socket é uma extremidade de comunicação, frequentemente usada em rede.
• Chamada de sistema é um pedido controlado do programa ao kernel.
• Entrada/saída (I/O, de input/output) é a comunicação com arquivo, rede ou dispositivo.

Modelo mental: uma cozinha administrada

Imagine que a receita é o programa; um cozinheiro preparando um pedido é o processo; pequenas tigelas à mão são registradores e cache; a bancada é RAM; a despensa persistente é armazenamento; e a gerência do prédio é o sistema operacional. Vários cozinheiros compartilham fogão e despensa segundo regras.

A analogia tem limites. CPU alterna tarefas em intervalos minúsculos, dados são copiados em hierarquias e memória virtual não corresponde a uma bancada física exclusiva. Além disso, uma thread não é outro cozinheiro completamente independente: threads do mesmo processo compartilham grande parte do estado.

Progressão 1 — da eletricidade às instruções

Transistores funcionam como componentes de comutação. Muitos deles formam circuitos capazes de representar estados e executar operações. A CPU busca uma instrução, decodifica o que ela significa e realiza a operação. Esse ciclo ocorre em enorme velocidade, mas frequência não é uma medida completa: arquitetura, número de núcleos, cache, paralelismo e natureza da tarefa também importam.

Registradores são extremamente pequenos e rápidos. Caches L1, L2 e L3 mantêm blocos próximos. RAM é maior e mais lenta; SSD é muito maior, persistente e mais lento. Essa hierarquia de memória explica por que acessar dados vizinhos repetidamente costuma ser mais eficiente que saltar aleatoriamente por uma coleção enorme. O programa geralmente não controla cada cópia: compilador, runtime, hardware e SO cooperam.

Progressão 2 — do arquivo ao processo

Código Python permanece texto até o interpretador lê-lo. Código Java costuma ser compilado para bytecode, executado pela máquina virtual Java. Código nativo pode ser compilado para instruções da plataforma. As rotas diferem, mas todas precisam de um processo criado pelo SO.

O processo recebe um espaço de endereçamento virtual, recursos abertos, permissões e ao menos uma thread. O mesmo programa pode originar vários processos com PIDs e estados diferentes. Fechar um processo não apaga o arquivo do programa; alterar um arquivo não muda necessariamente um processo já carregado.

Memória virtual oferece a cada processo uma visão organizada de endereços. O SO e o hardware traduzem esses endereços para memória física e podem mover páginas. Isso melhora isolamento e administração, mas não cria RAM infinita. Quando a demanda excede recursos, o sistema pode paginar intensamente, negar alocação ou encerrar processos.

Termos stack e heap aparecem em diagnósticos. A stack costuma guardar quadros de chamadas, parâmetros e variáveis locais; o heap abriga objetos com vida dinâmica. A divisão exata depende do runtime. “Heap” não é sinônimo de toda a RAM usada, e memória alta não prova vazamento. Um cache pode crescer e estabilizar de forma intencional; vazamento é retenção não desejada que continua comprometendo o sistema.

Progressão 3 — threads, concorrência e espera

Uma thread executa uma sequência de instruções. Threads do mesmo processo compartilham objetos e arquivos, então duas podem intercalar ações. estoque = estoque - 1 parece uma ação, mas envolve ler, calcular e escrever. Duas threads podem ler o mesmo valor e perder uma atualização.

Locks, filas, transações e dados imutáveis controlam concorrência, porém adicionam custo. Dois locks adquiridos em ordens opostas podem causar deadlock, quando cada thread espera pela outra. Antes de adicionar sincronização, reduza estado compartilhado e determine se paralelismo é necessário.

Uma tarefa CPU-bound é limitada por cálculo; uma tarefa I/O-bound, por espera de arquivo ou rede. Mais threads podem aproveitar períodos de espera, mas não criam capacidade infinita. Para cálculo, runtime, número de núcleos e divisão do trabalho definem o ganho. Trocas de contexto e contenção podem piorar desempenho.

Progressão 4 — arquivos, caminhos e durabilidade

Um caminho absoluto parte de uma raiz conhecida. Um caminho relativo é interpretado a partir do diretório atual do processo, não necessariamente da pasta onde o código está. Assim, o mesmo programa pode encontrar dados/ordens.json quando iniciado de uma pasta e falhar em outra.

Extensão sugere um formato, mas não garante conteúdo. Um arquivo chamado .json pode conter texto inválido. Abrir exige permissão; ler e escrever são permissões diferentes. O SO representa recursos abertos por identificadores ou handles. Se o programa nunca fecha arquivos e sockets, pode atingir o limite disponível.

write retornar com sucesso pode significar que bytes chegaram a um buffer, não à mídia física. flush, sincronização, sistema de arquivos e semântica do banco influenciam durabilidade. Por isso, memória, arquivo local e transação confirmada não são garantias equivalentes.

Progressão 5 — fronteiras e isolamento

Programas comuns executam em modo usuário. Para abrir um arquivo ou criar uma conexão, fazem uma chamada de sistema ao kernel, que verifica permissões. Essa fronteira impede que qualquer programa controle diretamente todo o hardware.

Uma máquina virtual oferece hardware virtualizado e normalmente um kernel próprio. Um contêiner compartilha o kernel do host, isolando processos com mecanismos como namespaces e limites. Contêineres iniciam rapidamente e ajudam reprodutibilidade, mas não são máquinas virtuais nem fronteiras perfeitas. Uma imagem vulnerável, execução privilegiada ou volume sensível montado reduz o isolamento. Sandbox é uma política combinada de permissões e contenção; pode usar contêiner, máquina virtual ou mecanismos específicos.

Antes e agora

Aplicações antigas eram frequentemente instaladas num servidor fixo e investigadas entrando manualmente na máquina. Isso ainda existe. Hoje, processos podem viver em contêineres efêmeros, escalar horizontalmente e ser substituídos automaticamente. Logs, métricas e rastreamento precisam sair do processo antes que ele desapareça. “Reiniciar para ver se resolve” é ainda mais perigoso quando destrói a única evidência local.

Também mudou a abstração: serviços gerenciados escondem hardware e kernel, mas não eliminam CPU, memória, limites e I/O. A equipe troca controle direto por uma interface operacional e continua responsável por medir comportamento, custos e permissões.

Exemplo executável, bloco a bloco

Crie observar.py. Primeiro, reúna identificadores do ambiente:

from pathlib import Path
import json
import os
import platform

alvo = Path("dados") / "ordens.json"
diagnostico = {
    "pid": os.getpid(),
    "diretorio_atual": str(Path.cwd()),
    "alvo_absoluto": str(alvo.resolve()),
    "sistema": platform.system(),
}
print(json.dumps(diagnostico, ensure_ascii=False, indent=2))

os.getpid() identifica a execução. Path.cwd() revela de onde caminhos relativos partem. resolve() mostra o alvo calculado sem pressupor que ele exista. platform.system() registra o SO para reproduzir diferenças.

Agora crie o diretório e persista um registro:

alvo.parent.mkdir(parents=True, exist_ok=True)

registros = [{"ordem": 1842, "status": "aberta"}]
with alvo.open("w", encoding="utf-8") as arquivo:
    json.dump(registros, arquivo, ensure_ascii=False, indent=2)

print("bytes gravados:", alvo.stat().st_size)
input("Pressione Enter para encerrar...")

mkdir garante a pasta. with fecha o arquivo. stat() consulta metadados. input mantém o processo vivo para que você o localize. Execute python observar.py; no Windows, abra o Gerenciador de Tarefas ou use Get-Process -Id NUMERO. Em Linux/macOS, use ps -p NUMERO.

O programa é didático: sobrescreve o arquivo e não trata concorrência. Não use esse padrão como banco de ordens. A finalidade é observar processo, caminho e persistência.

Aplicação em manutenção e ERP

Ao consultar uma ordem, o navegador cria uma requisição; a API recebe por um socket; um processo valida permissão; o serviço consulta o ERP ou banco; bytes retornam pela rede. Cada etapa possui latência e falhas próprias. Se a API estiver com CPU baixa e resposta lenta, pode estar esperando o ERP. Aumentar CPU não resolve espera externa.

Processos de importação precisam de idempotência: repetir um lote não deve duplicar ordens. Arquivos temporários devem ter pasta, permissão e ciclo de vida definidos. Em contêiner, gravar no sistema de arquivos local pode perder dados quando a instância é substituída; persistência exige volume ou serviço apropriado.

Falhas e diagnóstico por camada

Use a sequência “sintoma, medição, hipótese, experimento”:

• arquivo não encontrado: registre diretório atual e alvo absoluto; não conclua que o arquivo inexiste;
• CPU alta: identifique processo, núcleo, duração e operação; pode ser carga legítima ou loop;
• CPU baixa e lentidão: meça espera de disco, rede, lock ou serviço externo;
• memória crescente: observe se estabiliza, relacione com carga e faça perfil antes de chamar de vazamento;
• disco cheio: verifique logs, temporários e retenção; apagar sem política apenas adia;
• muitos arquivos abertos: conte recursos e localize caminhos que não fecham;
• processo encerrado: preserve código de saída, horário e logs antes de reiniciar.

Um valor médio pode esconder o problema: 25% de CPU numa máquina de quatro núcleos pode representar um núcleo totalmente ocupado. Compare séries no tempo, não apenas uma fotografia.

Segurança, privacidade e custo

Execute serviços com usuário sem privilégio administrativo e conceda somente pastas e conexões necessárias. Não coloque senha em argumentos de linha de comando, pois listas de processos podem expô-la. Proteja temporários, limite CPU e memória e não monte diretórios pessoais em contêineres de teste.

Logs ajudam diagnóstico, mas podem vazar tokens, nomes e ordens. Registre identificadores mínimos, mascare segredos e controle retenção. Capacidade ociosa demais custa; limite apertado demais causa indisponibilidade. Meça picos e mantenha margem justificada.

Exercício guiado

Execute observar.py em duas pastas diferentes. Anote PID, diretório atual, alvo absoluto e tamanho. Antes da segunda execução, preveja onde o arquivo será criado. Depois encerre o processo e confirme: PID e variáveis desapareceram; o arquivo permaneceu.

Altere dados para uma pasta sem permissão de escrita em um ambiente descartável. Registre a mensagem e reverta. Não execute como administrador para contornar o erro; isso mudaria a fronteira de segurança em vez de corrigir a configuração.

Desafio e evidência

Produza um relatório com diagrama da execução, comandos, horários, duas previsões e observações. Explique um cenário CPU-bound e um I/O-bound do sistema de manutenção. Uma segunda pessoa deve localizar o processo e o arquivo apenas com o relatório.

Critérios de aceite:

• processo, PID, thread e programa são distinguidos corretamente;
• o relatório prova o que persistiu após encerrar;
• caminho absoluto e diretório atual aparecem na evidência;
• pelo menos uma hipótese foi descartada por medição;
• nenhum segredo ou dado real aparece;
• limitações do exemplo estão declaradas.

Conclusão e recuperação ativa

Código armazenado torna-se uma execução por meio de compilador ou runtime, processo e sistema operacional. CPU calcula, RAM sustenta estado temporário, armazenamento persiste e I/O conecta o programa ao exterior. Feche o texto e desenhe o caminho de uma consulta do navegador ao arquivo. Explique por que processo não é programa, por que thread não é processo e por que contêiner não equivale automaticamente a uma fronteira segura.

Fontes oficiais

• Linux kernel documentation: processos, memória, sistemas de arquivos e interfaces do kernel.
• Microsoft — About System Information: conceitos e interfaces oficiais de informações do Windows.
• Python — Execution model: modelo oficial da execução Python.
• Oracle — Java Virtual Machine Specification, Java SE 21: exemplo normativo de máquina virtual e execução de bytecode.