Quando comecei na programação, o fato de um código meu consumir 100% de CPU era muito preocupante. Neste artigo, vou falar um pouco sobre isso e descrever por que cada vez menos programadores estão se preocupando com esse problema, cujo principal sintoma é a lentidão.

Um dos tópicos importantes que aprendemos quando estamos dando os primeiros passos na programação tradicional é o uso de estruturas de repetição, tais como o while ou for. Essas estruturas são relativamente independentes de linguagem de programação e, se mal utilizadas, podem causar o famoso sintoma de 100% de CPU. Geralmente isso acontece quando se há um problema do tipo loop infinito, no qual o fluxo de execução roda indefinidamente por algum erro no controle do índice ou da expressão lógica que faz a saída do loop. Também é comum problemas de IO relacionados a programação síncrona gerarem custo excessivo de CPU.

Quando comecei a aprender programação, sempre me preocupei com os recursos computacionais, pois meu aprendizado inicial foi em uma época na qual o hardware (CPU, memória, disco, IO, tela etc.) era limitado. Portanto, fazia muito sentido descobrir se algum programa meu acabou entrando em um loop infinito ou por algum outro motivo utilizava muita CPU, ao ponto de as ferramentas de monitoria do sistema operacional indicarem o consumo de 100%.

Atualmente, o cenário é bem diferente: temos diversos núcleos no processador (cores) que escalonam processos, máquinas virtuais como uma camada a mais na programação (máquinas virtuais do Java e .NET framework da Microsoft), servidores completamente virtualizados e separados do hardware principal, consoles de videogame e dispositivos móveis que possuem poucos recursos para monitorar CPU e uma abundância de recursos computacionais. Isso sem contar os diferentes contextos e camadas onde é possível programar (dentro do banco de dados com SQL, no lado cliente de um browser com JavaScript, dentro de um controlador em uma placa Arduino etc.). Às vezes fico com a impressão de que a técnica de programar e verificar se o que foi feito gera 100% de consumo de CPU é uma arte que está sendo perdida com o tempo….

Acredito que mesmo com tantos contextos, tecnologias e formas diferentes de se programar, um profissional deve, no mínimo, saber monitorar e ver se o seu programa está consumindo muitos recursos e produzindo o famigerado 100% de consumo de CPU. A propósito, existem diversos problemas que podem ser gerados quando a CPU é consumida a 100% por muito tempo. Além da maior demanda por refrigeração do processador ou microcontrolador, o sistema operacional não terá ciclos suficientes para realizar suas tarefas e, no pior caso, o sistema ficará completamente travado, gerando problemas de usabilidade em aplicações Web, banco de dados, jogos mobile e outros. Há também questões de custo, se considerarmos um código que roda dentro de uma plataforma de nuvem que cobra por uso de CPU. Enfim, esse não é um cenário desejado para quem desenvolve aplicações.

Se um programador não ficar atento ao consumo de CPI do seu código, é possível que ele atribua os problemas a outras origens. Não raro encontro programadores que culpam o hardware pela lentidão de sistemas sendo que, na verdade, algum pedaço de software foi mal escrito e está causando 100% de CPU. É verdade que atualmente existem muitos recursos automáticos do ambiente de execução e produção de código que evitam o consumo excessivo de CPU, mas mesmo assim isso ainda acontece. E nem sempre é por causa de um loop infinito.