Une I/O bloquante arrête le thread appelant jusqu'à la fin de l'opération ; une I/O non bloquante retourne immédiatement et laisse le thread faire autre chose pendant que l'opération s'achève. Sync contre async décrit la même idée au niveau de l'API.
read() jusqu'à l'arrivée des données. Simple, mais le thread reste inactif pendant tout ce temps — pour servir N clients lents il vous faut N threads.Bloquant : ──[ attend le disque ]── (thread bloqué, ne fait rien)
Non bloquant : ──▶ retourne tout de suite ; l'event loop est notifié quand c'est prêt
// Bloquant : rien d'autre ne s'exécute tant que le fichier n'est pas lu
const data = fs.readFileSync('big.txt');
// Non bloquant : le thread continue ; le callback se déclenche plus tard
fs.readFile('big.txt', (err, data) => { /* traiter plus tard */ });
// ou async/await au-dessus de primitives non bloquantes
const data2 = await fs.promises.readFile('big.txt');
C'est le cœur des serveurs qui passent à l'échelle. Node.js et nginx gèrent d'énormes quantités de connexions avec peu de threads précisément parce que l'I/O est non bloquante — attendre ne monopolise pas un thread. Utilisez des appels bloquants pour la simplicité dans les scripts ; utilisez du non bloquant pour les services réseau à forte concurrence, et ne bloquez jamais l'event loop avec du travail gourmand en CPU.
Une bibliothèque de questions d'entretien IT avec des réponses détaillées — du Junior au Senior.
Faire un don