Az IntelliJ UI responsiveness évek óta visszatérő probléma a JetBrains IDE-knél. A JetBrains most publikálta a többéves átalakítás aktuális állapotát: a háttérbe költöztetett write action-ök harmadára csökkentették a UI thread zárolását. A projekt még nem ért véget, de a mérési adatok fejlesztők számára is tanulságosak.
A 25 éves zárolási modell és az EDT terhelése
Az IntelliJ Platform többszálú keretrendszer egyetlen read-write lockkal. Minden magadatstruktúra a zároláson megy keresztül. Idetartozik a szintaxisfa (PSI), a Document és a Virtual File System. A write action kizárólagos hozzáférést kap. Amíg fut, egyetlen read action sem folyhat párhuzamosan.
A Java AWT egyetlen UI szálat használ. Ezt a szálat hívják EDT-nek. Az EDT festi a képernyőt és feldolgozza a felhasználói bemenetet. A Java engedi, hogy üzleti logika is itt fusson. Az egyszerűség évekig jól működött, de a modern terhelést nem bírta.
A freeze két forrásból jön. Vagy maga a write action hosszú, például szintaxisfa újraparsolásnál. Vagy az EDT a write lockra vár, miközben egy read action még fut. Egyetlen nem megszakítható read action elég a bajhoz. A felhasználó ezt rövid akadásokként érzékeli gépelés vagy navigálás közben.
Háttér write action: az IntelliJ UI responsiveness kulcsa
A cél világos volt: vidd el a write actionöket az EDT-ről. A munka 2019-ben indult. 2020-ban a projekt megállt a túl nagy refaktor miatt. Sok UI komponens, elsősorban a szerkesztő, hallgatólagos előfeltételekre épített az EDT-n. 2022-ben újraindult a csapat. A JetBrains Research-csel közösen új, megszakítható zárolást terveztek. A régi ReentrantReadWriteLock nem felelt meg az új igényeknek.
A kulcs a write-intent lock state. Ez még párhuzamos read actionöket enged. Egyszerre csak egy szál tarthatja. A state atomikusan léptethető write actionné. Az EDT-n maradó kód így átülhet a background write-ra a létező szerződések elrontása nélkül. A backward compatibility megőrzése kritikus volt a plugin ökoszisztéma miatt.
A modalitás külön kihívás volt. Egy modal dialog ablak alatt a platform nem engedhet független write actionöket. Különben a modell inkonzisztens állapotba kerül. A JetBrains modality-aware locking stratégiát épített. A stratégia szétválasztja a dialóguson belüli és kívüli műveleteket. A background write-ok és a modal workflow-k így nem akadnak deadlockba.
A VFS refresh volt az első nagy migráció. A fájlrendszer eseményeinek szinkronizálása a write actionben fut. A lépés plugin listenereket is hív. Sok listener az EDT-n futást feltételezte, és nem módosítható kód. A JetBrains az invokeAndWait trükkel inkrementálisan adta át az EDT-re a kompatibilitást igénylő hívásokat. A document commit migrációja ezután már könnyebb volt.
Amit a fejlesztő elvisz az IntelliJ UI responsiveness munkából
A mérések beszélnek. A 2025.2 verzióban a felhasználók UI idejének 1,83 százaléka ment write actionre. A 2025.3-ban ez 0,53 százalékra csökkent. A csökkenés közel harmadnyi. A különbséget egy villámgyorsabb IDE-n lehet érezni gépelés és fájlnavigáció közben. A JetBrains minden új kiadásnál publikálja a friss adatokat.
A tanulság szélesebb, mint egyetlen IDE sorsa. Régi, lock-intenzív rendszereknél a compatibility shim nélküli tiszta refaktor gyakran lehetetlen. A JetBrains megoldása más: inkrementálisan elvinni a lassú műveleteket, és a létező kontraktusokat szinkron handoff-fal fenntartani. A módszer kulcsa a fokozatos migráció és a kutatás alapú lock-design. Más platformok is tanulhatnak belőle.
A minta más területekre is érvényes. A JetBrains AI kódolási eszközök felmérése és az infrastruktúra-zaj a kódoló ágens benchmarkokban cikk hasonló mintát mutat. A platform döntések évekig meghatározzák a felhasználói élményt. A refaktor költsége mindig magas, de a halogatás többe kerül.
A következő lépés egyszerű: olvasd el a JetBrains Platform blog teljes cikkét a technikai részletekért. Plugin fejlesztőként érdemes áttekinteni a listenerek EDT-függőségét a következő migráció előtt. A write action menete évek alatt változik, de a backward compatibility megmarad. A JetBrains jövőbeli terve a gépelésnél is eltüntetni a lock igényét. A változás az Actions, a PSI és a Document alap-struktúrákat is érinti. Ez hosszú munka lesz a következő kiadások során.
