yoklateknik mülakat
GelişimGeçmiş

Frontend Javascript Memory Performance Mülakat Soruları

75 doğrulanmış Frontend Javascript Memory Performance mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Javascript Memory PerformanceZorluk 1
JavaScript'te 'memory leak' (bellek sızıntısı) en doğru şekilde nedir?
  • aGarbage collector'ın herhangi bir anda çalışması
  • bProgramın artık ihtiyaç duymadığı ama erişilebilir kalan ve hiç geri alınamayan bellek✓
  • cJS motorunu anında çökerten bir sözdizimi hatası
  • dCall stack yerine heap'te ayrılan bellek
Açıklama:Sızıntı, GC'nin çalışıp çalışmamasıyla ilgili değildir — nesnelerin (unutulan bir referans yüzünden) programın gerçek bir kullanımı kalmadıktan çok sonra bile erişilebilir kalmasıyla ilgilidir; bu yüzden GC bunları serbest bırakabileceğini bilemez.
Javascript Memory PerformanceZorluk 2
Modern JS motorlarının kullandığı garbage collection stratejisi 'mark-and-sweep'i en iyi hangisi tanımlar?
  • aHer nesne, sıfıra düşünce onu serbest bırakan bir referans sayacı tutar
  • bBellek, nesneleri heap'in başına taşıyarak birleştirilir
  • cMotor, kök referanslardan erişilebilen her şeyi işaretler, sonra işaretsizi süpürür✓
  • dBelirli bir milisaniyeden daha uzun süredir var olan nesneler arka plandaki bir zamanlayıcı tarafından otomatik olarak serbest bırakılır
Açıklama:Mark-and-sweep, GC köklerinden başlayıp referansları takip ederek erişilebilen her şeyi işaretler, sonra işaretlenmeyeni siler. Bu yüzden naif reference counting'in aksine erişilemez döngüler (cycle) de sorunsuz toplanır.
Javascript Memory PerformanceZorluk 2
function makeCycle() {
  let a = {};
  let b = {};
  a.other = b;
  b.other = a;
  return "done";
}
makeCycle();

makeCycle() döndükten sonra a, b ve işaret ettikleri nesneler garbage collection'a uygun mu?
  • aEvet — fonksiyon dışında kimse onlara referans vermez, bu yüzden erişilemez döngü toplanır✓
  • bHayır — a ve b birbirine karşılıklı referans tuttuğu için motor bunların gerçekte erişilemez olduğunu asla belirleyemez
  • cYalnızca a toplanır; b ikinci atandığı için hayatta kalır
  • dYalnızca önce delete a.other çağrılırsa
Açıklama:Reference counting bu döngüde takılırdı (sayaç asla sıfıra inmez), ama mark-and-sweep bunu umursamaz — makeCycle döndükten sonra köklerden erişilebilen hiçbir şey a veya b'yi işaret etmediği için ikisi birlikte toplanır.
Javascript Memory PerformanceZorluk 2
Bir SPA, bir component'in 'mount' aşamasında güncellemeleri sormak için setInterval başlatıyor ama kullanıcı sayfadan ayrıldığında clearInterval hiç çağrılmıyor. En olası sonuç nedir?
  • aHiçbir şey — DOM node kaldırılınca setInterval callback'i GC'ye alınır
  • bTarayıcı sekmesi hemen çöker
  • cDOM node'u erişilemez olunca interval kendini durdurur
  • dÇalışmaya devam eder — closure'ı sayfa ömrü boyunca canlı kalır ve tekrarlanan navigasyonlarda birikir✓
Açıklama:Çalışan bir timer, runtime tarafından tutulan, köke bağlı bir referanstır; bu yüzden clearInterval çağrılana kadar callback closure'ı toplanamaz. Yalnızca DOM'dan kaldırma bunu durdurmaz.
Javascript Memory PerformanceZorluk 2
const detached = [];
function cacheRow(row) {
  detached.push(row);
  row.remove();
}

cacheRow, <tr> elementleriyle tekrar tekrar çağrılırsa zamanla ne olur?
  • aKaldırılan satırlar, dizi olsun olmasın .remove() çalışır çalışmaz toplanır
  • bHer satır bellekte kalır çünkü detached hâlâ referans veriyor — detached DOM tree sızıntısı✓
  • cBir satır dokümandan ayrılınca tarayıcı detached'ı otomatik temizler
  • dElement başka yerden referanslı olduğu için row.remove() hata fırlatır
Açıklama:.remove() yalnızca elementi görünür doküman ağacından ayırır; JS erişilebilirliğini etkilemez. detached referansı tuttuğu sürece (artık görünmez olan) DOM alt ağacı bellekte kalmaya devam eder.
Javascript Memory PerformanceZorluk 3
Bir widget'ın constructor'ı her seferinde yepyeni bir closure fonksiyonu oluşturup window'a bir resize listener'ı olarak ekliyor ama widget yok edildiğinde hiç kaldırmıyor. Uygulama bu widget'ı bir oturumda 50 kez oluşturup yok ediyor. Etkisi ne olur?
  • awindow üzerinde 50 closure birikir, her biri kendi widget örneğini canlı tutar✓
  • bYalnızca en yeni listener hayatta kalır; yinelenenler otomatik değiştirilir
  • caddEventListener özdeş fonksiyon referanslarını otomatik tekilleştirir
  • dresize yalnızca ara sıra tetiklendiği için bellek etkisi yoktur
Açıklama:Farklı bir closure ile yapılan her addEventListener çağrısı yeni bir listener ekler; köke bağlı bir nesne olan window bunların hepsine canlı referans tutar, bu da her widget örneğinin closure'ını (ve yakaladığı her şeyi) canlı tutar.

Uzmanlığa göre

Angular 450JavaScript 450React 450TypeScript 450Vue 450

Kıdeme göre

Frontend JuniorFrontend MidFrontend Senior

Diğer alanlar

BackendFullstackDevOps / CloudAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

2925 soruluk Frontend bankasında kendini sına.

Mülakata başla