JavaScript-ul tău rulează pe un singur thread, dar așteptarea nu. Node predă I/O-ul de rețea sistemului de operare (epoll, kqueue, IOCP) și operațiile pe sistemul de fișiere thread pool-ului din libuv, apoi rulează callback-ul tău pe thread-ul principal când rezultatul e gata. Thread-ul principal nu așteaptă niciodată; doar rulează callback-uri.

O buclă din libuv care trece ciclic prin faze: timers, pending callbacks, poll (I/O), check (setImmediate) și close callbacks. Fiecare fază are o coadă, iar fiecare callback rulează până la capăt pe stiva de apeluri înainte să înceapă următorul.

Mai întâi codul sincron. Apoi toată coada nextTick, apoi toată coada de microtask-uri a promise-urilor. Abia după aceea bucla trece la callback-urile setTimeout din faza timers și la setImmediate din faza check. Ambele cozi de microtask-uri sunt golite din nou după fiecare callback în parte.

Node pornește un modul ES din interiorul unui job de promise, așa că, atunci când codul de la nivelul superior se termină, V8 încă golește coada de microtask-uri și rulează callback-urile de promise-uri pe care le-ai pus în coadă înainte ca Node să ajungă la coada nextTick. În CommonJS, coada nextTick vine prima. Exemplele de pe această linie sunt CommonJS: rulează scenariul 1 ca fișier .mjs și C și D își schimbă locurile.

Din modulul principal nu e garantat; depinde de cât de repede pornește bucla. Într-un callback de I/O, setImmediate câștigă întotdeauna, pentru că faza check vine imediat după faza poll.

Rulează munca pentru care sistemul de operare nu are un API neblocant: majoritatea apelurilor fs, dns.lookup și funcțiile crypto și zlib care consumă mult CPU. Are implicit 4 thread-uri, număr setat prin UV_THREADPOOL_SIZE. Socket-urile de rețea nu îl folosesc.

Orice muncă sincronă de durată: un JSON.parse uriaș, apeluri sincrone fs sau crypto, bucle grele, un regex cu backtracking catastrofal. Cât timp rulează, nicio cerere, niciun timer și niciun promise nu pot avansa. Împarte munca în bucăți, procesează datele ca stream sau mut-o în worker_threads.

Întârzierea unui timer e un minim, nu o garanție. Callback-ul rulează în prima fază timers de după expirarea întârzierii, așa că un callback lung dinaintea lui îl întârzie, exact ca în scenariul loop done at 100 ms de pe această linie.

Da. Coada nextTick e golită complet înainte ca bucla să continue, așa că un callback care programează mereu un alt nextTick oprește tot I/O-ul. setImmediate, în schimb, lasă loc I/O-ului.

worker_threads rulează JavaScript în paralel în același proces și pot partaja memorie prin SharedArrayBuffer; folosește-le pentru sarcini care consumă mult CPU. cluster, sau mai multe procese în spatele unui load balancer, rulează procese Node separate, astfel încât un server să poată folosi toate nucleele.

Macrotask-urile sunt callback-urile pe care bucla le preia fază cu fază: timere, callback-uri de I/O, setImmediate, evenimente close. Microtask-urile sunt reacțiile promise-urilor și callback-urile queueMicrotask, plus coada proprie a Node, nextTick. După fiecare callback de macrotask, Node golește complet ambele cozi de microtask-uri înainte să-l ruleze pe următorul.

queueMicrotask pune un callback în coada de microtask-uri a V8, aceeași coadă pe care o folosesc callback-urile de promise-uri. process.nextTick folosește o coadă separată a Node care, în CommonJS, rulează înaintea ei. Preferă queueMicrotask: funcționează la fel în browsere și în Node și nu poate trece înaintea promise-urilor pe care le-ai pus deja în coadă.

Bucla cere sistemului de operare operațiile de I/O terminate și rulează callback-urile lor. Dacă nu are nimic de rulat, așteaptă acolo I/O nou, dar doar până când vine rândul celui mai apropiat timer. Dacă există un setImmediate în coadă, nu așteaptă deloc și trece direct la faza check.

O funcție async rulează sincron până la primul await. Acolo îi returnează apelantului un promise în așteptare (pending), iar restul funcției e reluat mai târziu ca microtask, după ce valoarea așteptată e finalizată (settled). Nimic nu rulează în paralel: await doar îți împarte funcția în callback-uri.

Începând cu Node 15, o respingere netratată emite unhandledRejection, iar dacă nimic nu o tratează, e aruncată ca excepție neprinsă și procesul se încheie cu eroare. Într-un handler uncaughtException, loghează și ieși: procesul e într-o stare necunoscută, așa că lasă un supervisor să-l repornească în loc să continui.

Nu. Variantele cu promise, cu callback și sincronă ale fs fac aceeași muncă; cele asincrone o rulează pe thread pool-ul din libuv și diferă doar prin felul în care primești rezultatul. I/O-ul de rețea, inclusiv fetch și http, e partea care merge direct la sistemul de operare, fără pool.

dns.lookup, pe care http și net îl folosesc implicit, apelează getaddrinfo pe thread pool. Cu doar 4 thread-uri, câteva lookup-uri lente pot ocupa tot pool-ul, iar operațiile fs, crypto și zlib se adună la coadă în spatele lor. Mărește UV_THREADPOOL_SIZE, pune lookup-urile în cache sau folosește dns.resolve, care interoghează direct rețeaua.

Stream-urile mută datele în bucăți (chunk-uri) în loc să le încarce pe toate odată, așa că un fișier de 10 GB folosește la fel de multă memorie ca unul de 10 KB, iar procesarea începe de la prima bucată. Există patru tipuri: Readable, Writable, Duplex (ambele, ca un socket) și Transform (un Duplex care modifică datele, ca gzip).

E ce se întâmplă când producătorul e mai rapid decât consumatorul. write() returnează false când bufferul intern depășește highWaterMark, iar tu ar trebui să te oprești din scris până la 'drain'. Dacă ignori semnalul, bufferul crește până când procesul rămâne fără memorie. pipe() și pipeline() se ocupă de asta în locul tău.

.pipe() nu propagă erorile: dacă un stream eșuează, celelalte rămân deschise, iar descriptorii de fișiere sau socket-urile nu mai sunt eliberați (leak). pipeline() distruge toate stream-urile când oricare dintre ele eșuează și îți dă un singur callback, sau un singur promise din stream/promises, pentru succes sau eroare.

Nu. emit() apelează sincron fiecare listener, în ordinea în care au fost adăugați, pe stiva de apeluri curentă, și revine doar după ce toți au terminat. Un listener lent blochează emitterul. Iar un eveniment 'error' fără listener aruncă o excepție.

Măsoară întârzierea: perf_hooks.monitorEventLoopDelay() îți dă o histogramă a întârzierilor buclei, iar performance.eventLoopUtilization() arată cât de ocupată e. Ca să găsești cauza, fă un profil CPU cu --cpu-prof sau cu inspectorul și caută frame-uri sincrone lungi în flame graph.

setInterval se declanșează după program, indiferent dacă rularea asincronă anterioară s-a terminat, așa că cererile lente se suprapun și se adună. Dacă programezi următorul setTimeout la finalul fiecărei rulări, garantezi o pauză între rulări, iar back-off-ul devine ușor de implementat.

Fiecare worker are propriul isolate V8 și propriul event loop, deci implicit nu se partajează nimic. postMessage copiază datele cu algoritmul structured clone; dacă treci un ArrayBuffer în lista de obiecte transferabile, el este mutat în loc să fie copiat. Doar un SharedArrayBuffer este partajat cu adevărat, iar accesul la el îl coordonezi cu Atomics.

spawn pornește un program și îi transmite ieșirea ca stream. exec rulează o comandă printr-un shell și ține ieșirea într-un buffer, așa că e expus la shell injection și limitat de maxBuffer. execFile este exec fără shell. fork pornește un alt proces Node cu un canal IPC pentru send() și 'message'.

La SIGTERM, apelează server.close() ca să nu mai accepți conexiuni noi și să lași cererile în curs să se termine; închide conexiunile keep-alive inactive (closeIdleConnections()); apoi închide pool-urile de conexiuni la baza de date și cozile, și ieși. Adaugă un timeout strict, ca o cerere blocată să nu poată ține procesul în viață la nesfârșit.

Transportă context, cum ar fi ID-ul cererii sau utilizatorul curent, prin fiecare callback și await care decurge dintr-o cerere, fără să-l transmiți ca argument. Este echivalentul async al thread-local storage și așa etichetează loggerele și instrumentele de tracing tot ce se face pentru o cerere.

Cu un AbortController. Transmiți proprietatea lui signal către fetch, fs.readFile, versiunile cu promise ale timerelor, events.once sau propriile tale funcții, apoi apelezi abort(). AbortSignal.timeout(ms) îți dă un semnal care se declanșează singur.

Event loop-ul rulează cât timp ceva încă îl ține deschis: un timer, un socket sau un server deschis, un pool de conexiuni la baza de date, un proces copil. Închide ce ai deschis. Pentru un handle care n-ar trebui să țină singur procesul în viață, cum ar fi un interval de fundal, apelează .unref().

Nu rulează nimic: operațiile au pornit când ai creat promise-urile, iar Promise.all doar le așteaptă. Așteptarea e concurentă, iar promise-ul returnat e respins imediat ce unul dintre ele e respins, fără să le anuleze pe celelalte. Folosește allSettled ca să obții toate rezultatele, any pentru primul succes, race pentru primul care se finalizează și un limitator precum p-limit când ai mii de task-uri.

Se creează un singur obiect listă în heap, iar ambele nume se referă la el. Atribuirea nu copiază niciodată: leagă un nume de un obiect, iar numărul de referințe al listei ajunge la 2.

Niciuna. Transmite prin valoare referințe la obiecte, ceea ce se numește adesea call by sharing. O funcție poate modifica un obiect pe care i-l dai și vei vedea schimbarea, dar dacă funcția leagă parametrul de alt obiect, variabila ta nu e afectată.

În principal prin numărarea referințelor: când numărul de referințe al unui obiect scade la zero, obiectul e eliberat imediat. Un garbage collector generațional pentru cicluri găsește grupuri de obiecte care se referă doar unele la altele, pe care numărarea referințelor singură nu le poate elibera niciodată.

is verifică identitatea: sunt acestea același obiect? == verifică egalitatea prin __eq__. Folosește is pentru singleton-uri precum None și == pentru tot restul.

CPython păstrează în cache întregii de la -5 la 256, așa că aceștia sunt mereu aceleași obiecte. Dacă alte numere sau șiruri egale împart același obiect depinde de interning și de constant folding, un detaliu de implementare pe care nu trebuie să te bazezi niciodată.

Nu direct. del șterge un nume (sau un element dintr-un container) și decrementează numărul de referințe. Obiectul e eliberat doar când numărul ajunge la zero, sau mai târziu de garbage collector, dacă face parte dintr-un ciclu.

Obiectele mici vin din pymalloc, care ia memorie de la sistemul de operare în arene mari și poate returna o arenă doar când fiecare bloc din ea e liber. Câteva obiecte supraviețuitoare țin în viață arene întregi, cum arată demo-ul pymalloc de pe această linie. Python refolosește memoria respectivă; doar că n-o dă înapoi.

Caută referințe care trăiesc prea mult: cache-uri la nivel de modul, un functools.lru_cache nelimitat, closure-uri și callback-uri care captează obiecte mari, și variabile globale. tracemalloc arată ce linii au alocat memoria care rămâne ocupată, iar gc.get_referrers() arată cine ține referințe la un obiect.

Pentru cache-uri și referințe înapoi (back-references) care n-ar trebui să țină un obiect în viață. O referință slabă nu crește numărul de referințe, așa că obiectul poate fi totuși eliberat, după care referința slabă returnează None.

Fiecare obiect CPython are un contor al referințelor care indică spre el: nume, sloturi de listă, valori din dict, atribute. Legarea unui nume adaugă una, renunțarea la el scade una, iar la zero obiectul e eliberat imediat. sys.getrefcount(x) îl arată, cu unu mai mare decât te-ai aștepta, pentru că apelul însuși deține o referință.

Începând cu Python 3.12 (PEP 683), obiecte precum None, True, False, întregii mici și multe șiruri internate au un număr de referințe fix, care nu se schimbă niciodată, și nu sunt eliberate niciodată. Fără acele scrieri în contor se economisește muncă, paginile de memorie rămân partajate după fork, iar partajarea lor între thread-uri și interpretoare devine sigură.

Numărarea referințelor nu poate elibera ciclurile. Dacă o listă se conține pe ea însăși sau două obiecte indică unul spre celălalt, numărul lor de referințe nu ajunge niciodată la zero, chiar dacă nimic altceva nu le mai poate accesa. Colectorul de cicluri găsește astfel de grupuri scăzând referințele pe care și le țin unul altuia și le eliberează pe cele care rămân fără referințe din exterior.

Colectorul sortează obiectele container după vârstă. Obiectele noi încep în generația cea mai tânără, scanată des pentru că majoritatea obiectelor mor tinere; supraviețuitorii sunt promovați în generații mai vechi, scanate din ce în ce mai rar. Pragurile din gc.get_threshold() decid când rulează fiecare.

Rareori. Numărarea referințelor eliberează aproape totul, iar colectorul rulează deja singur. Dezactivarea lui e sigură doar dacă codul tău nu creează niciodată cicluri; altfel, ele rămân în memorie (leak). Singura ajustare frecventă este gc.freeze() înainte de fork-ul workerilor, ca colectorul să nu atingă (și astfel să nu copieze) paginile partajate de procesele copil.

Este un finalizator care rulează când un obiect e pe cale să fie eliberat. Momentul depinde de numărul de referințe, de cicluri și de implementarea Python, așa că nu e un loc bun pentru închiderea fișierelor sau a conexiunilor, iar excepțiile ridicate în el sunt doar afișate. Folosește în schimb un context manager (with) sau weakref.finalize.

Alocatorul CPython pentru obiecte mici, de cel mult 512 octeți. Ia arene mari de la sistemul de operare, le împarte în pool-uri, iar fiecare pool oferă blocuri dintr-o singură clasă de dimensiune. Astfel, crearea și eliberarea obiectelor mici nu costă aproape nimic, pentru că majoritatea cererilor nu ajung niciodată la alocatorul sistemului.

Măsoară doar obiectul în sine. Pentru o listă, asta înseamnă antetul plus array-ul de pointeri, nu obiectele spre care indică aceștia. O listă de o mie de șiruri raportează câțiva kilobytes, oricât de lungi ar fi șirurile. Ca să măsori toată structura, parcurge-o sau compară snapshot-uri tracemalloc înainte și după.

Înlocuiește dicționarul __dict__ al fiecărei instanțe cu sloturi fixe chiar în obiect. Fiecare instanță devine mai mică, iar accesul la atribute puțin mai rapid, ceea ce contează când creezi milioane de instanțe. Costul: nu poți adăuga atribute care nu sunt listate și ai nevoie de un slot __weakref__ pentru referințe slabe.

Păstrarea unei singure copii pentru șirurile egale. CPython internează automat identificatorii și multe literale scurte, iar pe altele le poți interna cu sys.intern(), ceea ce economisește memorie și accelerează căutările în dict pe chei repetate. E o optimizare, nu o regulă, așa că compară întotdeauna șirurile cu ==, niciodată cu is.

După fork, părintele și copilul partajează paginile de memorie până când unul dintre ei scrie într-o pagină. În CPython, simpla citire a unui obiect îi modifică numărul de referințe, ceea ce e o scriere, așa că paginile partajate sunt copiate una câte una. Obiectele imortale și gc.freeze() reduc acest efect.

O listă este un array redimensionabil de pointeri către obiecte stocate în altă parte. Când e plină, CPython alocă un array mai mare, cu spațiu de rezervă, așa că majoritatea operațiilor append doar ocupă un slot liber, iar copierea ocazională se amortizează: O(1) amortizat. Inserarea sau ștergerea la început este O(n), pentru că toți pointerii de după se mută.

Fiecare element este un pointer (8 octeți) către un obiect int complet (28 de octeți sau mai mult), cu propriul antet. array.array('q') sau un array NumPy stochează în schimb valorile brute de 8 octeți una lângă alta, de câteva ori mai compact și mult mai rapid de parcurs în C.

Un generator produce valorile pe rând și păstrează între ele doar frame-ul său suspendat. sum(x * x for x in range(10**8)) are nevoie de memorie constantă, în timp ce varianta cu list comprehension construiește mai întâi o listă de o sută de milioane de int-uri. Capcana: un generator poate fi consumat o singură dată.

O vedere asupra memoriei altui obiect care suportă buffer protocol, cum ar fi bytes, bytearray sau array. Un slice dintr-un memoryview nu copiază datele, așa că parsarea bucată cu bucată a unui buffer binar mare rămâne rapidă și nu folosește memorie suplimentară.

O funcție imbricată păstrează într-o celulă (cell) fiecare variabilă pe care o folosește din scope-ul exterior. Cât timp funcția există, de exemplu stocată ca callback, acele obiecte nu pot fi eliberate, chiar dacă aveai nevoie doar de o valoare mică dintr-unul uriaș. Extrage ce-ți trebuie înainte să definești funcția.

Un traceback are referințe la fiecare frame prin care a trecut, iar fiecare frame are referințe la variabilele sale locale. Dacă stochezi o excepție, de exemplu într-o listă de erori, toate acele variabile locale rămân în viață. De aceea Python șterge numele după except E as e:; stochează str(e) dacă ai nevoie doar de mesaj.

Păstrează o referință la fiecare argument și rezultat pe care îl stochează. Cu maxsize=None sau @cache, crește la nesfârșit. Pe o metodă stochează și self, ceea ce ține în viață fiecare instanță. Dă-i o dimensiune limitată și pune în cache funcții, nu metode.

Un întreg unic pentru un obiect cât timp acesta trăiește. În CPython este adresa din memorie. După ce un obiect e eliberat, un obiect nou poate primi aceeași adresă, așa că două obiecte diferite, create unul după altul, pot raporta același id.

Fără GIL, actualizările contorului din thread-uri diferite ar produce un race condition (condiție de cursă). Build-urile free-threaded folosesc biased reference counting: thread-ul care deține un obiect actualizează un contor local fără operații atomice, iar celelalte thread-uri actualizează atomic un contor partajat. Unele obiecte folosesc numărare amânată (deferred), iar memoria vine din mimalloc în loc de pymalloc.

Global Interpreter Lock este un mutex din CPython care lasă un singur thread să ruleze bytecode Python la un moment dat, în cadrul unui interpretor. Astfel, componentele interne ale interpretorului, cum ar fi numărul de referințe, rămân sigure fără lock-uri granulare.

Pentru că un thread eliberează GIL-ul cât timp așteaptă: I/O blocant pe socketuri și fișiere, precum și time.sleep, lasă alte thread-uri să ruleze. Multe extensii C, cum ar fi NumPy și hashlib pe date de intrare mari, îl eliberează și în timpul calculelor grele.

Folosește procese (multiprocessing sau concurrent.futures.ProcessPoolExecutor), ca fiecare worker să aibă propriul interpretor și propriul GIL, mută bucla critică în cod nativ care eliberează GIL-ul sau rulează pe build-ul free-threaded.

Nu. Thread-urile pot comuta între oricare două instrucțiuni bytecode, așa că count += 1 (citire, adunare, scriere) se poate intercala și pierde actualizări; e exact race condition-ul (condiția de cursă) pe care îl poți parcurge pas cu pas pe această linie. Protejează starea partajată cu threading.Lock sau transmite datele între thread-uri prin queue.Queue.

Un thread care așteaptă GIL-ul îl cere după intervalul de comutare, implicit 5 ms (sys.getswitchinterval()), iar thread-ul care îl deține îl eliberează la următorul punct sigur. Un thread care începe o operație I/O blocantă îl eliberează imediat.

Un build CPython separat, fără GIL (PEP 703), adăugat experimental în 3.13 ca python3.13t și suportat oficial din 3.14 (PEP 779). Thread-urile pot rula atunci cod Python pe mai multe nuclee simultan, cu un cost la viteza pe un singur thread. sys._is_gil_enabled() îți spune în ce mod ești.

asyncio pentru multe task-uri I/O concurente, cu biblioteci async, pe un singur thread. Thread-uri pentru I/O cu biblioteci blocante sau pentru câteva task-uri în fundal. Procese pentru Python pur limitat de CPU, plătind timpul de pornire și serializarea (pickling) datelor între ele.

Un thread limitat de CPU ține GIL-ul câte un interval de comutare întreg, așa că thread-urile de I/O, care au nevoie de el doar o clipă după fiecare citire, stau la coadă în spatele lui. Latența lor crește, deși volumul total de lucru aproape nu se schimbă, cum arată sarcina mixtă de pe această linie.

Nu, face parte din CPython, implementarea de referință. Jython și IronPython n-au avut niciodată GIL, PyPy are propriul GIL, iar din 3.13 CPython are un build free-threaded opțional, fără el. Limbajul spune doar ce înseamnă programul tău, nu cum sunt planificate thread-urile.

E o metodă simplă de a proteja componentele interne ale interpretorului: numărul de referințe, alocatorul și obiectele built-in pot fi actualizate fără un lock propriu. Asta păstrează rapid codul single-threaded și face extensiile C ușor de scris, cu prețul că un singur thread rulează bytecode Python la un moment dat.

În timpul I/O blocant (socketuri, fișiere, time.sleep) și în codul C care alege să-l elibereze, cum ar fi multe operații NumPy, hashlib pe date mari și zlib. Cât execută bytecode Python, thread-ul curent cedează GIL-ul și atunci când alt thread l-a așteptat un interval de comutare, implicit 5 ms.

Fără el, fiecare modificare a numărului de referințe ar necesita o operație atomică sau un lock, ceea ce a încetinit codul single-threaded în încercările anterioare, iar multe extensii C se bazau tacit pe GIL pentru siguranță. PEP 703 a rezolvat asta cu biased reference counting, lock-uri per obiect și obiecte nemuritoare (immortal objects), și vine ca build opțional.

Nu. Se compilează în mai mulți pași: citește valoarea, adună unu, o scrie înapoi, iar o comutare de thread între citire și scriere pierde o actualizare. Operațiile simple pe tipurile built-in, cum ar fi list.append, se întâmplă să fie atomice în CPython, dar nu te baza pe asta; protejează starea partajată cu un Lock.

Un Lock intră în deadlock dacă thread-ul care îl deține încearcă să-l obțină din nou. Un RLock (lock reentrant) lasă thread-ul proprietar să-l obțină de mai multe ori și se eliberează după tot atâtea eliberări. Folosește RLock când o metodă care ține lock-ul apelează altă metodă cu lock a aceluiași obiect.

Obține lock-urile mereu în aceeași ordine globală, ține-le cât mai puțin, folosește with ca să fie eliberate întotdeauna și nu apela niciodată cod necunoscut, cum ar fi callback-uri, cât timp ții un lock. Un timeout la acquire transformă un blocaj tăcut într-o eroare vizibilă.

Prin queue.Queue. Își gestionează singură lock-urile, blochează consumatorii până sosesc elemente și producătorii când e plină, și transformă starea partajată în mesaje. Pentru semnalizare, folosește threading.Event; ca să limitezi câte thread-uri folosesc o resursă, Semaphore.

Au în comun API-ul concurrent.futures, deci alegerea ține de tipul de lucru. Thread-uri pentru task-uri limitate de I/O: pornesc ieftin și partajează memoria. Procese pentru task-uri limitate de CPU: ocolesc GIL-ul, dar funcția și argumentele ei trebuie să poată fi serializate cu pickle, iar fiecare apel plătește trimiterea datelor către alt proces.

Pornirea proceselor, serializarea cu pickle a fiecărui argument și rezultat ca să treacă dintr-un proces în altul, plus o copie separată a interpretorului și a datelor în fiecare proces. Modul de pornire depinde de platformă: spawn pe Windows și macOS, forkserver pe Linux din 3.14 (înainte, fork).

Procesul copil primește o copie a memoriei, dar doar thread-ul care a apelat fork. Un lock ținut în acel moment de orice alt thread rămâne blocat pentru totdeauna în copil, așa că acesta se poate bloca la primul apel de logging sau la prima alocare. Python 3.12 și versiunile ulterioare avertizează despre asta; preferă spawn sau forkserver.

Trimite mesaje printr-un multiprocessing.Queue sau Pipe; datele sunt serializate cu pickle și copiate. Pentru array-uri mari, folosește multiprocessing.shared_memory, care dă fiecărui proces aceiași octeți, fără copiere. Un Manager partajează obiecte Python printr-un proces server, ceea ce e comod, dar lent.

Nu. Rulează un singur thread, iar task-urile își dau rândul la fiecare await. Așa gestionează ieftin mii de conexiuni care așteaptă, dar un singur apel blocant, cum ar fi time.sleep sau requests.get, îngheață toate task-urile. Mută lucrul blocant în afara event loop-ului cu asyncio.to_thread sau run_in_executor.

Concurența înseamnă să te ocupi de mai multe lucruri deodată: task-urile avansează pe rând. Paralelismul înseamnă să faci mai multe lucruri deodată: task-urile rulează în același moment pe nuclee diferite. Thread-urile sub GIL și asyncio îți dau concurență; procesele și Python free-threaded îți dau paralelism.

Adesea, da. NumPy eliberează GIL-ul în multe operații pe array-uri mari, așa că mai multe thread-uri le pot rula pe nuclee diferite. Liniile Python dintre aceste apeluri tot își așteaptă rândul, așa că câștigul depinde de cât din timp se petrece în NumPy.

Mai multe interpretoare Python izolate în același proces. Din 3.12 fiecare poate avea propriul GIL (PEP 684), iar 3.14 adaugă modulul concurrent.interpreters și InterpreterPoolExecutor. Obții paralelism cu overhead mai mic decât la procese, dar obiectele nu sunt partajate; datele se transmit între interpretoare.

Apelează sys._is_gil_enabled() (3.13 sau mai nou). Un build free-threaded, de obicei numit python3.13t sau python3.14t, rulează fără el, dar reactivează GIL-ul când importă o extensie C care nu e marcată ca sigură, dacă nu îl forțezi să rămână oprit cu PYTHON_GIL=0 sau -X gil=0.

Nu. Obiectele built-in își pun intern lock-uri, deci o listă nu se va corupe, dar counter += 1 și codul de tip check-then-act (verifici, apoi acționezi) au race condition exact ca înainte, doar mai des, pentru că acum thread-urile rulează cu adevărat simultan. Tot ai nevoie de lock-uri, iar codul single-threaded rulează ceva mai lent în acest build.

threading.local() dă fiecărui thread propria copie a unor atribute, cum ar fi o conexiune la baza de date. contextvars face același lucru pentru task-urile asyncio, care împart un singur thread, și funcționează și cu thread-uri. Pentru date legate de un request în cod async, folosește contextvars.

Nu îl poți omorî din afară. Dă-i un threading.Event și pune-l să verifice regulat evenimentul și să iasă. Un thread daemon (daemon=True) nu împiedică interpretorul să se închidă, dar e omorât fără curățenie, așa că fișierele deschise și tranzacțiile pot rămâne la jumătate.

Șapte primitive (undefined, null, boolean, number, bigint, string și symbol), plus obiecte. Array-urile, funcțiile, datele calendaristice, map-urile și instanțele de clasă sunt toate obiecte.

Opt șiruri: "undefined", "boolean", "number", "bigint", "string", "symbol", "object" și "function". typeof null este "object" din cauza unui bug istoric, așa că verifică null cu === null, iar array-urile cu Array.isArray().

Folosește implicit ===, care nu convertește niciodată tipurile. == aplică reguli de conversie: null și undefined sunt egale doar între ele, valorile booleene devin numere, un șir comparat cu un număr devine număr, iar obiectele sunt convertite în primitive. Singura utilizare uzuală a lui == este x == null, care verifică dacă valoarea e null sau undefined.

Nu. Totul se transmite prin valoare, dar valoarea unei variabile de tip obiect este o referință. O funcție poate modifica obiectul pe care i-l dai, dar reatribuirea parametrului nu îți schimbă variabila. În Python e la fel.

Spread-ul, Object.assign și slice() copiază un singur nivel, așa că obiectele imbricate rămân partajate. structuredClone face o copie profundă, inclusiv pentru Map, Set, Date și referințe circulare, dar aruncă o excepție la funcții, iar instanțele de clasă devin obiecte simple.

Numerele sunt double-uri IEEE 754 pe 64 de biți, iar 0.1, 0.2 și 0.3 nu au o reprezentare binară exactă, așa că fiecare e stocat ca cel mai apropiat double, iar erorile de rotunjire nu se anulează reciproc. Compară cu o toleranță sau ține sumele de bani ca întregi, în cenți.

false, 0, -0, 0n, "", null, undefined și NaN (plus vechiul document.all din browsere). Orice altceva e truthy, inclusiv "0", "false", [] și {}.

2⁵³ − 1. Peste această valoare, nu orice întreg poate fi reprezentat, așa că un ID pe 64 de biți dintr-o bază de date se poate schimba pe tăcute când e parsat ca număr. Păstrează astfel de ID-uri ca șiruri sau ca BigInt.

undefined înseamnă că o valoare n-a fost setată niciodată: o proprietate lipsă, o variabilă neatribuită, o funcție fără return. null este un „fără valoare” explicit, pe care îl atribui tu. JSON are null, dar nu are undefined, iar JSON.stringify omite proprietățile a căror valoare este undefined.

Un bug din primul motor JavaScript: valorile aveau o etichetă de tip, obiectele aveau eticheta 0, iar null era pointerul null, care se citea tot ca 0. Dacă s-ar schimba acum, s-ar strica web-ul, așa că rămâne așa. Verifică null cu x === null.

Array.isArray(x). typeof returnează "object", iar instanceof Array eșuează pentru array-uri din alt realm, cum ar fi un iframe sau un context vm, pentru că fiecare realm are propriul constructor Array.

Valoarea IEEE 754 pentru un rezultat nedefinit, cum ar fi 0 / 0 sau Number("abc"). Tipul lui este number și nu este egal cu nimic, nici măcar cu el însuși, așa că x === NaN e mereu false. Folosește Number.isNaN(x); funcția globală isNaN convertește mai întâi, așa că isNaN("abc") este true.

Exact în două cazuri: Object.is(NaN, NaN) este true, iar Object.is(0, -0) este false. În rest se comportă ca ===. React îl folosește ca să decidă dacă state-ul s-a schimbat, iar Map, Set și includes folosesc o variantă care consideră 0 și -0 egale.

Când scrii "abc".toUpperCase(), motorul folosește un wrapper String temporar ca să găsească metoda în String.prototype; primitiva în sine nu se schimbă. Nu crea niciodată wrappere de mână cu new String sau new Boolean: new Boolean(false) este un obiect, deci e truthy.

Apelează obj[Symbol.toPrimitive](hint), dacă există. Altfel, încearcă valueOf() și apoi toString() pentru un hint numeric, și invers pentru un hint de tip șir. De aceea [] + {} dă "[object Object]": [] devine "", {} devine "[object Object]", iar + concatenează șirurile.

Un tip întreg de orice mărime, scris 123n, pentru care typeof dă "bigint". Folosește-l pentru ID-uri, sume de bani în subunități sau orice depășește 2⁵³. Nu îl poți amesteca cu numere în operații aritmetice (1n + 1 aruncă un TypeError), nu are zecimale, iar JSON.stringify aruncă o excepție când îl întâlnește.

E o valoare unică, folosită mai ales ca cheie de proprietate care nu se poate ciocni cu nicio altă cheie, nici măcar cu una cu aceeași descriere. for...in, Object.keys și JSON.stringify ignoră cheile de tip symbol. Cele predefinite, ca Symbol.iterator, îți permit să conectezi obiectele la facilități ale limbajului, cum ar fi for...of.

Nu. const te împiedică doar să reasociezi numele; obiectul spre care arată se poate schimba în continuare. Object.freeze blochează modificările proprietăților proprii ale obiectului, dar e superficial: obiectele imbricate rămân mutabile dacă nu le îngheți și pe ele.

Preferă structuredClone: copiază Date, Map, Set, typed arrays și referințe circulare. Drumul dus-întors prin JSON pierde undefined și funcțiile, transformă datele calendaristice în șiruri și NaN în null, și aruncă o excepție la cicluri și la BigInt. Niciuna dintre variante nu copiază funcții și nu păstrează prototipurile claselor.

Un întreg mic pe care V8 îl stochează chiar în pointer, marcat prin bitul cel mai puțin semnificativ, așa că nu necesită alocare. Numerele care nu încap, cum ar fi fracțiile, -0 sau întregii mari, devin HeapNumber: un float pe 64 de biți într-un obiect separat pe heap. De aceea codul care lucrează mult cu întregi e adesea mai rapid.

V8 dă fiecărui obiect o clasă ascunsă, sau shape, care reține proprietățile lui și locul în care sunt stocate. Obiectele construite cu aceleași proprietăți, în aceeași ordine, au același shape, așa că accesul la proprietăți poate fi pus în cache și devine foarte rapid. Adăugarea proprietăților în ordini diferite sau folosirea lui delete creează shape-uri noi și încetinește acel cod.

V8 ține evidența a ce conține un array: doar întregi mici, doar double-uri sau orice, și dacă are goluri. Array-urile packed de întregi mici sunt cele mai rapide. Tranzițiile merg într-un singur sens: după arr.push(1.5) sau un gol ca arr[100] = 1, acel array nu mai redevine niciodată rapid. new Array(n) pornește ca holey.

Float-urile IEEE 754 păstrează un bit de semn chiar și pentru zero. 0 === -0 este true, dar 1 / -0 este -Infinity, iar Object.is(0, -0) este false. Apare când o valoare negativă mică e rotunjită la zero și îți poate spune din ce direcție s-a apropiat o valoare de zero.

Stochează întregi în subunități, cum ar fi cenții, cu BigInt dacă pot deveni mari, sau folosește o bibliotecă de numere zecimale, și formatează cu Intl.NumberFormat. toFixed nu rezolvă problema: rotunjește valoarea binară, așa că (1.005).toFixed(2) dă "1.00", pentru că 1.005 este de fapt 1.00499999...

parseInt citește cifre până dă de altceva, așa că parseInt("12px") dă 12. Number convertește tot șirul sau returnează NaN, așa că Number("12px") dă NaN, dar Number("") dă 0. Dă-i mereu lui parseInt baza (radix) și nu-i da niciodată numere: parseInt(0.0000005) dă 5.

Pentru x == null, care e true doar pentru null și undefined, așa că le prinde pe amândouă dintr-o singură verificare. Multe ghiduri de stil permit exact acest caz și folosesc === în rest.

a || b recurge la b pentru orice valoare falsy, inclusiv 0, "" și false. a ?? b face asta doar pentru null și undefined. Pentru valori implicite ca count ?? 10 ai nevoie de ??, ca să păstrezi un 0 real.

Folosește un Map pentru dicționare cu chei dinamice: cheile pot fi orice valoare, inclusiv obiecte, are size, se iterează în ordinea inserării și nu are chei moștenite, ca __proto__, de care să-ți faci griji. Cheile unui obiect sunt mereu șiruri sau simboluri, iar cheile care arată ca întregi sunt listate primele, în ordine numerică. Folosește obiecte pentru înregistrări cu câmpuri fixe.

Ca să atașezi date la obiecte care nu sunt ale tale, fără să le ții în viață. Cheile trebuie să fie obiecte, iar odată ce o cheie nu mai e accesibilă din altă parte, intrarea poate fi colectată de garbage collector. Pentru că intrările pot dispărea oricând, un WeakMap nu poate fi iterat și nu are size. Utilizări tipice: cache-uri și date private pentru fiecare nod DOM.

list, dict, set și bytearray, plus majoritatea claselor pe care le scrii tu. int, float, complex, bool, str, bytes, tuple, frozenset, range și None sunt imutabile: orice „modificare” construiește un obiect nou.

Are nevoie de un __hash__ care nu se schimbă niciodată pe durata vieții obiectului, iar obiectele egale trebuie să aibă același hash. Doar obiectele hashable pot fi chei de dict sau elemente de set, de aceea o listă nu poate fi cheie, dar un tuplu de elemente hashable poate.

Sunt egale la comparare și au același hash, așa că dict-ul le tratează ca pe o singură cheie. Se păstrează primul obiect-cheie și se înlocuiește doar valoarea, cum arată pas cu pas exemplul de hashing de pe această linie.

Apelează a.__add__(b). Dacă acesta returnează NotImplemented, încearcă b.__radd__(a) și aruncă TypeError dacă amândouă renunță. Dacă tipul lui b este o subclasă a tipului lui a și suprascrie __radd__, b are prioritate.

Nu pentru tipurile mutabile. += apelează mai întâi __iadd__, care extinde o listă pe loc, așa că toate numele legate de acea listă văd schimbarea. Tipurile imutabile recurg la x = x + y și reasociază doar x. Tot de aceea pair[0] += [2] pe un tuplu și modifică lista, și aruncă o excepție.

Valorile implicite sunt evaluate o singură dată, la definirea funcției, așa că toate apelurile folosesc aceeași listă. Folosește items=None și creează o listă nouă în interiorul funcției.

None este un singleton, așa că identitatea e testul precis. E și mai rapid și nu poate fi păcălit de o clasă al cărei __eq__ răspunde da la orice.

O listă pentru o colecție ordonată pe care o modifici, un tuplu pentru o înregistrare fixă sau o cheie hashable, un set pentru unicitate și teste rapide de apartenență, iar un dict pentru căutare după cheie. Alege un frozenset când ai nevoie de un set hashable.

list(x), x.copy(), x[:] și copy.copy() fac copii superficiale: noul container conține aceleași obiecte interioare. copy.deepcopy() copiază totul recursiv.

+= apelează întâi list.__iadd__, care extinde pe loc lista din tuplu, apoi încearcă să stocheze rezultatul înapoi în t[0], ceea ce aruncă TypeError. Sloturile tuplului nu se pot schimba, dar obiectele din ele da. Din același motiv, un tuplu care conține o listă nu e hashable.

Obiectele egale trebuie să aibă hash-uri egale, iar hash-ul nu are voie să se schimbe cât timp obiectul se află într-un set sau dict. De aceea, când definești __eq__, __hash__ devine None: Python face clasa non-hashable până când definești un hash bazat pe aceleași câmpuri. @dataclass(frozen=True) le face pe amândouă pentru tine.

E o tabelă hash. Hash-ul cheii alege un slot dintr-un mic array de indecși, coliziunile se rezolvă prin sondarea altor sloturi (probing), iar indexul trimite într-un array compact de intrări păstrate în ordinea inserării. Căutările, inserările și ștergerile sunt O(1) în medie, iar o potrivire se confirmă cu is sau == pe cheie.

Da, ordinea inserării e garantată din Python 3.7. OrderedDict rămâne util: are move_to_end, comparația de egalitate ține cont de ordine și e la îndemână pentru cache-uri LRU. Set-urile nu au deloc ordine.

Pe Python îl interesează ce poate face un obiect, nu ce clasă are: orice are __iter__ poate fi parcurs într-o buclă, orice are read() poate ține loc de fișier. De obicei, codul pur și simplu încearcă operația și tratează excepția (EAFP). Pentru type checkere, typing.Protocol descrie o astfel de formă fără moștenire.

NotImplemented este o valoare pe care o returnezi dintr-o metodă binară precum __add__ sau __eq__ ca să spui „nu cunosc acest tip”, iar Python încearcă atunci metoda celuilalt operand. NotImplementedError este o excepție pe care o arunci într-o metodă pe care subclasele trebuie s-o suprascrie. Dacă o arunci pe prima sau o returnezi pe a doua, ai un bug în ambele cazuri.

Pentru a + b, când a nu are __add__ sau aceasta returnează NotImplemented, Python încearcă b.__radd__(a). O excepție: dacă tipul lui b e o subclasă a tipului lui a și suprascrie __radd__, metoda lui e încercată prima, ca subclasele să poată prelua controlul. Așa funcționează sum() pe tipuri proprii, pornind de la 0.

Nu. Python le ignoră când rulează codul; unelte precum mypy și pyright le verifică înainte de rulare. Sunt disponibile la runtime prin typing.get_type_hints() și annotationlib, iar așa validează datele biblioteci ca Pydantic și FastAPI. Din 3.14, adnotările sunt evaluate lazy, doar când le cere ceva.

Nu, int-urile au precizie arbitrară și cresc cât e nevoie; sys.maxsize e dimensiunea maximă a unui container, nu cel mai mare int. Int-urile mari doar devin mai lente. Din 3.11, conversia unui int cu peste 4300 de cifre în sau din string aruncă implicit ValueError, ca să prevină atacurile de tip denial-of-service.

// rotunjește în jos, spre minus infinit, deci -7 // 2 dă -4, iar % ia semnul împărțitorului: -7 % 2 dă 1. JavaScript, C și Java trunchiază în schimb spre zero. Și int(-3.5) trunchiază, dând -3.

Python rotunjește jumătățile la cel mai apropiat număr par (rotunjirea bancherului), deci round(2.5) dă 2, iar round(3.5) dă 4; asta evită o eroare sistematică atunci când aduni multe valori rotunjite. round(2.675, 2) dă 2.67, pentru că 2.675 nu poate fi stocat exact. Pentru bani, folosește decimal.Decimal.

str e text, o secvență de code point-uri Unicode. bytes sunt date brute pe 8 biți, din fișiere, socketuri sau hash-uri. Python 3 nu convertește niciodată implicit între ele: faci encode() din text în bytes și decode() din bytes în text la granițele programului, specificând encoding-ul, de obicei UTF-8.

len numără code point-uri, nu ce vezi. „é” poate fi un singur code point (U+00E9) sau două: „e” plus un accent combinant. Normalizează cu unicodedata.normalize("NFC", s) înainte să compari sau să numeri. Intern, CPython stochează fiecare string cu 1, 2 sau 4 octeți pe caracter, în funcție de cel mai lat caracter din el.

String-urile sunt imutabile, așa că fiecare += poate crea un string nou și copia tot ce s-a adunat până atunci, adică O(n²) în total. CPython extinde uneori pe loc, dar alte implementări nu, și nu te poți baza pe asta. Adună bucățile într-o listă și apelează o singură dată "".join(parts), sau folosește io.StringIO.

isinstance acceptă subclase și clase de bază abstracte precum collections.abc.Mapping, ceea ce e aproape mereu ce vrei. Are o surpriză clasică: bool e subclasă a lui int, deci isinstance(True, int) e adevărat, iar True + True dă 2. Folosește type(x) is T doar când subclasele trebuie respinse.

O listă verifică pe rând fiecare element: O(n). Set-urile și dict-urile calculează hash-ul lui x și se uită într-un singur slot: O(1) în medie. Să transformi o listă în set înainte să verifici mii de valori într-o buclă e una dintre cele mai simple optimizări cu câștig mare. Și x in range(...) e O(1): e doar aritmetică.

namedtuple: un tuplu imutabil și ușor, cu nume de câmpuri. dataclass: o clasă obișnuită cu __init__, __repr__ și __eq__ generate, mutabilă sau frozen, cu valori implicite și metode. TypedDict: type hints pentru dict-uri care rămân dict-uri simple, cum ar fi payload-urile JSON. Un dict simplu: chei cu adevărat dinamice.

Da. Sortarea din Python e stabilă, deci elementele cu chei egale își păstrează ordinea și poți sorta după mai multe chei în mai multe treceri, începând cu cea mai puțin importantă. E O(n log n) și foarte rapidă pe date deja parțial sortate. Are nevoie doar de <; dacă amesteci tipuri care nu pot fi comparate, cum ar fi None și int, primești TypeError.

Apelează __bool__ dacă clasa îl definește, altfel __len__, iar orice altceva e considerat adevărat. Așadar None, False, zero din orice tip numeric și containerele goale sunt falsy. Atenție la if not x: când 0 sau o listă goală sunt valori valide; scrie în schimb if x is None:.

Un iterabil, cum e o listă, îți poate da un iterator nou cu iter(), de câte ori vrei. Un iterator își ține minte poziția, returnează următorul element din __next__ și se consumă după o singură trecere. Generatoarele și obiectele fișier sunt iteratori, de aceea a doua parcurgere a unuia nu produce nimic.