Preparatório Caixa TI: Sistemas Operacionais — processos, memória e arquivos

Visão geral: o que um Sistema Operacional gerencia

Em ambientes corporativos, o Sistema Operacional (SO) é o componente que coordena recursos para que múltiplos programas e usuários coexistam com desempenho, isolamento e controle. Para provas, é comum separar o estudo em três pilares: (1) processos/threads e escalonamento, (2) memória (física e virtual), (3) sistemas de arquivos e permissões. A administração do SO aparece em cenários: identificar gargalos, interpretar estados, aplicar comandos e escolher a ação correta.

Gerenciamento de processos e threads

Conceitos essenciais

Processo é um programa em execução com seu próprio contexto: espaço de endereçamento, recursos (descritores de arquivos, sockets), credenciais e estado. Thread é uma linha de execução dentro de um processo; threads compartilham memória e recursos do processo, mas têm pilha e registradores próprios. Em geral, criar e alternar threads tende a ser mais leve que processos, mas aumenta a necessidade de sincronização por compartilharem dados.

• Estados típicos de um processo: novo, pronto (ready), executando (running), bloqueado/esperando (waiting/blocked), terminado (terminated).
• Troca de contexto: salvar/restaurar estado de CPU ao alternar entre processos/threads; tem custo e afeta desempenho quando há excesso de alternâncias.
• Chamadas de sistema: interface para operações privilegiadas (criar processo, abrir arquivo, alocar memória, etc.).

Passo a passo prático: identificar processos e consumo

Objetivo: localizar um processo que consome CPU/memória e entender seu estado.

• Listar processos (visão geral):

ps aux

• Filtrar por nome:

ps aux | grep nome_do_processo

• Ordenar por CPU:

ps aux --sort=-%cpu | head

• Ordenar por memória:

ps aux --sort=-%mem | head

• Visão dinâmica (interativa):

top

Interpretação típica: se um processo está em execução constante e com alta CPU, pode ser carga legítima ou loop; se está bloqueado, pode estar esperando I/O (disco/rede) ou um lock.

Escalonamento (alto nível)

Objetivos e métricas

Escalonamento é a política que decide quem usa a CPU e quando. Em provas, foque nos objetivos: justiça, tempo de resposta (interatividade), throughput (vazão), prioridades (tarefas críticas), e evitar starvation (fome: processo nunca executa).

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Algoritmos clássicos (visão conceitual)

• FCFS (First-Come, First-Served): simples; pode causar efeito comboio (tarefas curtas esperando longas).
• SJF/SRTF: favorece tarefas curtas; exige estimativa de duração; pode aumentar starvation de tarefas longas.
• Round Robin: fatias de tempo (quantum); bom para interatividade; quantum muito pequeno aumenta overhead de troca de contexto.
• Prioridades: processos com maior prioridade executam antes; precisa de mecanismos como aging para reduzir starvation.
• Filas multinível / feedback: separa por classes (interativo, batch) e ajusta prioridade conforme comportamento.

Passo a passo prático: ajustar prioridade (conceito de nice)

Em ambientes tipo Unix, a prioridade pode ser ajustada via nice (valor maior tende a significar menor prioridade de CPU para o processo).

• Iniciar um comando com prioridade ajustada:

nice -n 10 comando

• Ajustar prioridade de um processo existente:

renice 10 -p PID

Em cenários corporativos, isso é útil para reduzir impacto de tarefas batch (relatórios, compressão, rotinas) em servidores que precisam manter boa resposta para serviços online.

Sincronização, condições de corrida e deadlock

Condição de corrida e região crítica

Condição de corrida ocorre quando o resultado depende da ordem de execução de threads/processos concorrentes acessando dados compartilhados. A região crítica é o trecho que acessa o recurso compartilhado e deve ser protegido para garantir consistência.

Exemplo prático: duas threads incrementando um contador compartilhado sem proteção podem “perder” incrementos.

Mecanismos de sincronização (conceitos)

• Mutex (mutual exclusion): garante exclusão mútua; apenas uma thread entra na região crítica por vez.
• Semáforo: contador que controla acesso a um conjunto de recursos (ex.: pool de conexões); pode ser binário (similar a mutex) ou contável.
• Monitores/locks: abstrações que combinam exclusão mútua e condições de espera/sinalização.
• Operações atômicas: instruções que evitam interleaving (ex.: compare-and-swap), reduzindo necessidade de locks em alguns casos.

Deadlock: conceito e condições necessárias

Deadlock é um impasse em que processos/threads ficam bloqueados indefinidamente, cada um esperando por recursos mantidos por outros. Para ocorrer deadlock, as quatro condições (clássicas) precisam estar presentes simultaneamente:

• Exclusão mútua: ao menos um recurso não pode ser compartilhado.
• Posse e espera (hold and wait): um processo mantém recursos enquanto espera por outros.
• Não preempção: recursos não podem ser retirados à força; só liberados voluntariamente.
• Espera circular: existe um ciclo de processos esperando recursos uns dos outros.

Em provas, é comum perguntar como prevenir/evitar: quebrar uma das condições (por exemplo, impor ordenação global de aquisição de locks para impedir espera circular).

Exercício de cenário (interpretação)

Cenário: duas rotinas concorrentes usam dois locks: L1 (tabela A) e L2 (tabela B). Rotina X bloqueia L1 e depois tenta L2. Rotina Y bloqueia L2 e depois tenta L1. Em produção, ambas “travaram”.

• Pergunta: quais condições de deadlock aparecem claramente?
• O que fazer: padronizar a ordem de aquisição (sempre L1 depois L2) ou usar timeout/retry; isso atua sobre a condição de espera circular.

Gerenciamento de memória

Conceitos: memória física, virtual e endereçamento

Programas enxergam um espaço de endereços (memória virtual) que não precisa corresponder diretamente à RAM. O SO e o hardware (MMU) traduzem endereços virtuais em físicos, aplicando proteção (isolamento entre processos) e permitindo que a soma das memórias virtuais seja maior que a RAM disponível.

Paginação (paging)

Paginação divide a memória virtual em páginas e a memória física em quadros (frames) de tamanho fixo. A tradução usa tabelas de páginas. Vantagens: elimina fragmentação externa e simplifica alocação. Custo: pode haver fragmentação interna (espaço desperdiçado dentro da última página) e overhead de tabelas.

• Page fault: ocorre quando a página acessada não está na RAM; o SO precisa carregá-la do disco (ou mapear), o que é muito mais lento.

Segmentação

Segmentação divide o espaço de endereços em segmentos lógicos (código, dados, pilha), com tamanhos variáveis. Facilita proteção e compartilhamento por segmento, mas pode causar fragmentação externa e exigir compactação/realocação (dependendo da implementação).

Memória virtual e swap (troca)

Memória virtual permite que páginas/segmentos não usados no momento fiquem fora da RAM. Swap é o mecanismo de mover páginas entre RAM e área em disco (arquivo/partição de swap). Quando há pressão de memória, o SO pode trocar páginas pouco usadas para liberar RAM.

Ponto de prova: excesso de swap pode levar a thrashing (o sistema passa mais tempo trocando páginas do que executando trabalho útil), degradando drasticamente o desempenho.

Passo a passo prático: verificar memória e swap

• Resumo de memória:

free -h

• Detalhe de memória virtual e swap:

vmstat 1 5

• Ver uso por processo (visão geral):

top

Interpretação: se a coluna de swap in/out (no vmstat) mostra atividade constante e alta, e a latência do sistema aumenta, pode ser pressão de memória. Ações típicas: identificar processo “vazando” memória, ajustar limites, aumentar RAM, ou otimizar cache/serviço.

Sistemas de arquivos e permissões

O que um sistema de arquivos fornece

Um sistema de arquivos organiza dados em estruturas (arquivos e diretórios), mantém metadados (tamanho, dono, timestamps), controla permissões e garante consistência (dependendo do mecanismo de journaling/registro). Em corporações, o foco está em: controle de acesso, auditoria básica, disponibilidade e recuperação.

Permissões: visão prática (modelo Unix)

No modelo tradicional, permissões são atribuídas a usuário (owner), grupo e outros, com bits de leitura (r), escrita (w) e execução (x).

• Ver permissões:

ls -l

• Alterar permissões (exemplo: dono pode ler/escrever, grupo pode ler, outros sem acesso):

chmod 640 arquivo

• Alterar dono/grupo:

chown usuario:grupo arquivo

Interpretação comum: diretório precisa de permissão x para “atravessar” (acessar conteúdo por nome), e r para listar. Isso cai muito em questões de acesso negado em diretórios.

Inodes (Unix) vs NTFS (Windows): comparação objetiva

Em sistemas tipo Unix, o inode é uma estrutura que representa o arquivo e guarda metadados (permissões, dono, tamanho, ponteiros para blocos de dados). O nome do arquivo fica no diretório, que mapeia nome → inode. Isso explica por que hard links funcionam: múltiplos nomes podem apontar para o mesmo inode.

No NTFS, a ideia equivalente é uma estrutura de metadados central (como a MFT, Master File Table), onde registros descrevem arquivos e seus atributos. O NTFS trabalha com atributos e suporta recursos como permissões mais granulares via ACLs (listas de controle de acesso), além de links e recursos de integridade. Para prova, compare assim: inode/MFT são estruturas de metadados que permitem localizar dados e aplicar controle de acesso; a diferença prática é o modelo e granularidade de permissões (bits simples vs ACLs) e como o sistema representa atributos.

Passo a passo prático: diagnosticar “Permission denied”

Objetivo: entender por que um serviço não consegue ler um arquivo de configuração.

• 1) Verificar permissões e dono:

ls -l /caminho/arquivo.conf

• 2) Verificar permissões do diretório (travessia):

ls -ld /caminho /caminho/subdir

• 3) Confirmar usuário efetivo do processo (descobrir o usuário do serviço):

ps aux | grep nome_do_servico

• 4) Ajustar o mínimo necessário (exemplo: permitir leitura ao grupo do serviço):

chown root:grupo_do_servico /caminho/arquivo.conf chmod 640 /caminho/arquivo.conf

Em questões, a pegadinha comum é o diretório sem permissão de execução (x) para o usuário/grupo do serviço, mesmo que o arquivo tenha leitura.

Comandos e conceitos de administração essenciais (ambiente corporativo)

Processos: sinais e encerramento controlado

Quando um processo precisa ser finalizado, prefira encerramento gracioso antes de forçar.

• Enviar sinal (ex.: terminar):

kill PID

• Forçar encerramento (último recurso):

kill -9 PID

• Encerrar por nome:

pkill nome_do_processo

Interpretação: sinais permitem que o processo libere recursos; forçar pode deixar arquivos temporários, locks e inconsistências.

Disco e sistema de arquivos: espaço e pontos de montagem

• Uso de disco por filesystem:

df -h

• Uso por diretório (localizar “vilões”):

du -sh /caminho/*

Em cenários, “disco cheio” pode causar falhas em serviços (logs não gravam, banco não escreve, atualizações falham). A interpretação correta costuma envolver identificar partição/montagem específica cheia, não apenas “o disco”.

Arquivos abertos e troubleshooting

• Ver quais processos estão usando um arquivo/porta (quando disponível):

lsof | head

lsof /caminho/arquivo

Uso típico: arquivo de log crescendo sem controle; mesmo após apagar, o espaço não volta porque o processo mantém o descritor aberto. A correção é reiniciar/rotacionar o serviço para fechar e reabrir o arquivo.

Logs e auditoria básica

Em produção, logs são a principal evidência para entender falhas. O essencial é saber localizar e filtrar.

• Filtrar por palavra-chave:

grep -i "erro" /caminho/log.log

• Acompanhar log em tempo real:

tail -f /caminho/log.log

Exercícios de interpretação de cenários (estilo prova)

1) CPU alta após atualização

Cenário: após atualização de um serviço, o servidor apresenta lentidão. O comando top mostra um processo com 300% de CPU (máquina com múltiplos núcleos) e muitos threads.

• Pergunta: o que significa CPU > 100%?
• Resposta esperada: uso de múltiplos núcleos/threads; o processo está consumindo mais de um core.
• Ação provável: verificar regressão/loop, limitar prioridade (nice), checar logs e parâmetros; confirmar se é carga esperada.

2) Sistema “travando” com swap intenso

Cenário: free -h mostra pouca RAM livre e swap quase cheio; vmstat indica swap in/out constante.

• Pergunta: qual conceito explica a degradação?
• Resposta esperada: thrashing por pressão de memória; page faults frequentes e troca excessiva.
• Ação provável: identificar processo com alto consumo, reduzir carga, aumentar memória, ajustar limites/parametrização.

3) Erro de permissão em diretório

Cenário: um serviço precisa ler /app/conf/config.yml. O arquivo está com -rw-r----- e pertence ao grupo do serviço, mas ainda ocorre “Permission denied”. O diretório /app/conf está com drw-r-----.

• Pergunta: por que falha?
• Resposta esperada: falta permissão de execução (x) no diretório para atravessar; sem x, não acessa o arquivo mesmo com leitura nele.
• Correção típica: adicionar x ao diretório para o grupo adequado (ex.: chmod 750 /app/conf), mantendo princípio do menor privilégio.

4) Deadlock em rotina concorrente

Cenário: duas threads usam locks A e B. Em logs, Thread 1 “acquired A, waiting B”; Thread 2 “acquired B, waiting A”.

• Pergunta: qual condição de deadlock está evidenciada?
• Resposta esperada: espera circular (e também posse e espera).
• Mitigação: impor ordem fixa de aquisição (A depois B), ou usar try-lock com backoff/timeout.