SonarSource Rules
  • Products

    In-IDE

    Code Quality and Security in your IDE with SonarQube Ide

    IDE extension that lets you fix coding issues before they exist!

    Discover SonarQube for IDE

    SaaS

    Code Quality and Security in the cloud with SonarQube Cloud

    Setup is effortless and analysis is automatic for most languages

    Discover SonarQube Cloud

    Self-Hosted

    Code Quality and Security Self-Hosted with SonarQube Server

    Fast, accurate analysis; enterprise scalability

    Discover SonarQube Server
  • SecretsSecrets
  • ABAPABAP
  • AnsibleAnsible
  • ApexApex
  • AzureResourceManagerAzureResourceManager
  • CC
  • C#C#
  • C++C++
  • CloudFormationCloudFormation
  • COBOLCOBOL
  • CSSCSS
  • DartDart
  • DockerDocker
  • FlexFlex
  • GitHub ActionsGitHub Actions
  • GoGo
  • HTMLHTML
  • JavaJava
  • JavaScriptJavaScript
  • JSONJSON
  • JCLJCL
  • KotlinKotlin
  • KubernetesKubernetes
  • Objective CObjective C
  • PHPPHP
  • PL/IPL/I
  • PL/SQLPL/SQL
  • PythonPython
  • RPGRPG
  • RubyRuby
  • RustRust
  • ScalaScala
  • ShellShell
  • SwiftSwift
  • TerraformTerraform
  • TextText
  • TypeScriptTypeScript
  • T-SQLT-SQL
  • VB.NETVB.NET
  • VB6VB6
  • XMLXML
  • YAMLYAML
Java

Java static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code

  • All rules 733
  • Vulnerability60
  • Bug175
  • Security Hotspot40
  • Code Smell458

  • Quick Fix 65
Filtered: 32 rules found
multi-threading
    Impact
      Clean code attribute
        1. Virtual threads should not run tasks that include synchronized code

           Bug
        2. Virtual threads should be used for tasks that include heavy blocking operations

           Bug
        3. Overrides should match their parent class methods in synchronization

           Bug
        4. Value-based classes should not be used for locking

           Bug
        5. "this" should not be exposed from constructors

           Code Smell
        6. "volatile" variables should not be used with compound operators

           Bug
        7. Non-primitive fields should not be "volatile"

           Bug
        8. "getClass" should not be used for synchronization

           Bug
        9. Assignment of lazy-initialized members should be the last step with double-checked locking

           Bug
        10. "wait" should not be called when multiple locks are held

           Bug
        11. Getters and setters should be synchronized in pairs

           Bug
        12. Non-thread-safe fields should not be static

           Bug
        13. Instance methods should not write to "static" fields

           Code Smell
        14. Threads should not be started in constructors

           Code Smell
        15. "notifyAll()" should be preferred over "notify()"

           Bug
        16. Blocks should be synchronized on "private final" fields

           Bug
        17. Lazy initialization of "static" fields should be "synchronized"

           Code Smell
        18. Synchronizing on a "Lock" object should be avoided

           Code Smell
        19. "Thread" should not be used where a "Runnable" argument is expected

           Code Smell
        20. "wait(...)" should be used instead of "Thread.sleep(...)" when a lock is held

           Bug
        21. "Object.wait(...)" and "Condition.await(...)" should be called inside a "while" loop

           Code Smell
        22. "Object.wait()", "Object.notify()" and "Object.notifyAll()" should only be called from synchronized code

           Bug
        23. Methods "wait(...)", "notify()" and "notifyAll()" should not be called on Thread instances

           Bug
        24. "IllegalMonitorStateException" should not be caught

           Code Smell
        25. Servlets should not have mutable instance fields

           Bug
        26. Locks should be released on all paths

           Bug
        27. ".equals()" should not be used to test the values of "Atomic" classes

           Bug
        28. Double-checked locking should not be used

           Bug
        29. "InterruptedException" and "ThreadDeath" should not be ignored

           Bug
        30. Classes extending java.lang.Thread should provide a specific "run" behavior

           Bug
        31. Synchronization should not be done on instances of value-based classes

           Bug
        32. "Thread.run()" should not be called directly

           Bug

        Virtual threads should not run tasks that include synchronized code

        intentionality - logical
        reliability
        Bug
        • java21
        • multi-threading

        Why is this an issue?

        More Info

        Java virtual threads enable the JVM to optimize the use of OS threads by mounting and unmounting them as needed. This makes them more efficient when dealing with blocking operations such as I/O or HTTP requests.

        This rule applies only to code running on Java versions older than 24. Since Java 24, virtual threads are no longer pinned when executing synchronized code.

        For Java version 21 to 23, when code is executed inside a synchronized block or method, the virtual thread remains pinned to its underlying OS thread and cannot be unmounted during a blocking operation. This causes the OS thread to be blocked, which can impact the scalability of the application.

        Therefore, in environments running a Java version below 24, virtual threads should not execute code that contains synchronized blocks or invokes synchronized methods. Platform threads should be used in these cases instead.

        This rule raises an issue when a virtual thread contains synchronized blocks or invokes synchronized methods.

        Code examples

        Noncompliant code example

        void enqueue(){
            Thread.startVirtualThread(() -> { // Noncompliant; use a platform thread instead
                    setupOperations();
                    dequeLogic();
                }
            });
        }
        

        Compliant solution

        void enqueue(){
            new Thread(() -> {
                synchronized {
                    setupOperations();
                    dequeLogic();
                }
            }).start();
        }
        

        Noncompliant code example

        void enqueue2(){
            Thread.startVirtualThread(() -> { // Noncompliant; use a platform thread instead of a virtual one
                if(someCondition){
                    synchronizedMethod();
                }else{
                    defaultLogic();
                }
            });
        }
        synchronized void synchronizedMethod(){}
        void defaultLogic(){}
        

        Compliant solution

        void enqueue2(){
            new Thread(() -> {
                if(someCondition){
                    synchronizedMethod();
                }else{
                    defaultLogic();
                }
            }).start();
        }
        synchronized void synchronizedMethod(){}
        void defaultLogic(){}
        
          Available In:
        • SonarQube IdeCatch issues on the fly,
          in your IDE
        • SonarQube CloudDetect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories
        • SonarQube Community BuildAnalyze code in your
          on-premise CI
          Available Since
          10.5
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          10.5

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use