The UI is freezing, after no specific action occurred. I reproduced it myself, see thread dump attached.
After some investigation, here is the chain of events leading to a deadlock and a UI freeze:
A background thread (pooled) running an analysis flushes the findings on disk. It calls LiveFindingCache.replaceFinding, which is synchronized. This keyword was added in the previous release (SLI-1161). The thread is paused soon after.
The ActionUpdater thread (comes from IntelliJ) calls SonarLintTrafficLightAction.updatePresentation()from a read action
Down in updatePresentation() we call LiveFindingCache.getLive(), which is also synchronized.
The EDT is trying to handle key events and wants to start a write action. It is blocked as there is already a read action started at step 2.
The thread running the analysis resumes and tries to acquire a read action.
As a write action was requested at step 4, the read action requested at step 5 is blocked, even if another read action is already running. Write actions run in priority, as soon as previous read actions are finished.
This sequence leads to a deadlock, and a UI freeze as the write action started from the EDT is blocked forever
Solution
It is dangerous to have synchronization in the LiveFindingCache. We should aim at removing synchronized keywords from it. If still needed, the synchronized sections should be narrowed down to the minimum.
Attachments
1
Activity
Show:
Fixed
Pinned fields
Click on the next to a field label to start pinning.
The UI is freezing, after no specific action occurred. I reproduced it myself, see thread dump attached.
After some investigation, here is the chain of events leading to a deadlock and a UI freeze:
A background thread (pooled) running an analysis flushes the findings on disk. It calls
LiveFindingCache.replaceFinding, which issynchronized. This keyword was added in the previous release (SLI-1161). The thread is paused soon after.The
ActionUpdaterthread (comes from IntelliJ) callsSonarLintTrafficLightAction.updatePresentation()from a read actionDown in
updatePresentation()we callLiveFindingCache.getLive(), which is alsosynchronized.The EDT is trying to handle key events and wants to start a write action. It is blocked as there is already a read action started at step 2.
The thread running the analysis resumes and tries to acquire a read action.
As a write action was requested at step 4, the read action requested at step 5 is blocked, even if another read action is already running. Write actions run in priority, as soon as previous read actions are finished.
This sequence leads to a deadlock, and a UI freeze as the write action started from the EDT is blocked forever
Solution
It is dangerous to have synchronization in the
LiveFindingCache. We should aim at removingsynchronizedkeywords from it. If still needed, the synchronized sections should be narrowed down to the minimum.