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

        Non-thread-safe fields should not be static

        intentionality - logical
        reliability
        Bug
        • multi-threading

        Why is this an issue?

        How can I fix it?

        More Info

        When an object is marked as static, it means that it belongs to the class rather than any class instance. This means there is only one copy of the static object in memory, regardless of how many class instances are created. Static objects are shared among all instances of the class and can be accessed using the class name rather than an instance of the class.

        A data type is considered thread-safe if it can be used correctly by multiple threads, regardless of how those threads are executed, without requiring additional coordination from the calling code. In other words, a thread-safe data type can be accessed and modified by multiple threads simultaneously without causing any issues or requiring extra work from the programmer to ensure correct behavior.

        Non-thread-safe objects are objects that are not designed to be used in a multi-threaded environment and can lead to race conditions and data inconsistencies when accessed by multiple threads simultaneously. Using them in a multi-threaded manner is highly likely to cause data problems or exceptions at runtime.

        When a non-thread-safe object is marked as static in a multi-threaded environment, it can cause issues because the non-thread-safe object will be shared across different instances of the containing class.

        This rule raises an issue when any of the following instances and their subtypes are marked as static:

        • java.util.Calendar,
        • java.text.DateFormat,
        • javax.xml.xpath.XPath, or
        • javax.xml.validation.SchemaFactory.
          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
          9.1
        • SonarQube ServerAnalyze code in your
          on-premise CI
          Developer Edition
          Available Since
          9.1

        © 2008-2025 SonarSource SA. All rights reserved.

        Privacy Policy | Cookie Policy | Terms of Use