代码质量管理工具：SonarQube常见的问题及正确解决方案

╰半夏微凉° 2023-07-14 08:23 3阅读 0赞

SonarQube 简介

Sonar 是一个用于代码质量管理的开放平台。通过插件机制，Sonar 可以集成不同的测试工具，代码分析工具，以及持续集成工具。

与持续集成工具（例如 Hudson/Jenkins 等）不同，Sonar 并不是简单地把不同的代码检查工具结果（例如 FindBugs，PMD 等）直接显示在 Web 页面上，而是通过不同的插件对这些结果进行再加工处理，通过量化的方式度量代码质量的变化，从而可以方便地对不同规模和种类的工程进行代码质量管理。

在对其他工具的支持方面，Sonar 不仅提供了对 IDE 的支持，可以在 Eclipse 和 IntelliJ IDEA 这些工具里联机查看结果；同时 Sonar 还对大量的持续集成工具提供了接口支持，可以很方便地在持续集成中使用 Sonar。

此外，Sonar 的插件还可以对 Java 以外的其他编程语言提供支持，对国际化以及报告文档化也有良好的支持

![format_png][]

1."@RequestMapping" 方法应为“ public”

> 将调用具有@Controller注释的类的@RequestMapping注释部分的方法（直接或间接通过元注释-Spring Boot的@RestController是一个很好的示例）来处理匹配的Web请求。即使该方法是私有的，也会发生这种情况，因为Spring会通过反射调用此类方法，而不检查可见性。
> 
> 因此，将敏感方法标记为私有似乎是控制如何调用此类代码的好方法。不幸的是，并非所有的Spring框架都以这种方式忽略可见性。例如，如果您试图通过将其标记为@Secured来控制对敏感，私有@RequestMapping方法的Web访问，则无论用户是否被授权访问它，它仍将被调用。这是因为AOP代理不适用于非公开方法。
> 
> 除了@RequestMapping之外，此规则还考虑了Spring Framework 4.3中引入的注释：@ GetMapping，@ PostMapping，@ PutMapping，@ DeleteMapping，@ PatchMapping。

2.默认软件包中不应使用“ @SpringBootApplication”和“ @ComponentScan”

> @ComponentScan用于确定哪些Spring Bean在应用程序上下文中可用。可以使用basePackageClasses或basePackages（或其别名值）参数来配置要扫描的软件包。如果未配置任何参数，则@ComponentScan将仅考虑带有注释的类的程序包。在属于默认包的类上使用@ComponentScan时，将扫描整个类路径。
> 
> 这将减慢应用程序的启动速度，并且该应用程序可能无法启动BeanDefinitionStoreException，因为您最终扫描了Spring Framework软件包本身。
> 
> 在以下情况下，此规则会引起问题：
> 
> @ ComponentScan，@ SpringBootApplication和@ServletComponentScan用于默认包的类
> 
> @ComponentScan已使用默认程序包显式配置

**不兼容代码示例**

import org.springframework.boot.SpringApplication;
    @SpringBootApplication //不合规；RootBootApp在默认包中声明
    public class RootBootApp {
    ...
    }
    @ComponentScan("")
    public class Application {
    ...
    }

**兼容解决方案**

package hello;
    import org.springframework.boot.SpringApplication;
    @SpringBootApplication //合规 RootBootApp属于“ hello”包
    public class RootBootApp {
    ...
    }

3.不应使用双重检查锁定

双重检查锁定是在输入同步块之前和之后检查延迟初始化对象的状态，以确定是否初始化该对象。

如果不对float或int以外的任何可变实例进行额外同步，则无法以独立于平台的方式可靠地工作。使用延迟初始化的双重检查锁定任何其他类型的原始或可变对象风险第二个线程使用未初始化或部分初始化成员第一个线程仍然是创建它时,程序崩溃。

**有多种解决方法。最简单的方法是根本不使用双重检查锁定，而是同步整个方法。对于早期版本的JVM，出于性能原因，通常建议不要同步整个方法。但是，在新的JVM中，同步性能已大大提高，因此，现在这是首选的解决方案。如果您希望完全避免使用同步，则可以使用内部静态类来保存引用。内部静态类保证延迟加载。**

**不兼容代码示例**

@NotThreadSafe  //线程不安全
    public class DoubleCheckedLocking {
        private static Resource resource;
        public static Resource getInstance() {
            if (resource == null) {//2
                synchronized (DoubleCheckedLocking.class) {
                    if (resource == null)//1
                        resource = new Resource(); //第一个线程还没创建完，只是分配了内存，指了引用，线程执行上面，会判断resource != null,最终导致程序崩溃
                }
            }
            return resource;
        }
        static class Resource {
        }
    }

**兼容解决方案**

@ThreadSafe
    public class SafeLazyInitialization {
        private static Resource resource;
        public static synchronized Resource getInstance() {
            if (resource == null)
                resource = new Resource();
            return resource;
        }
        static class Resource {
        }
    }

@ThreadSafe
    public class ResourceFactory {
        private static class ResourceHolder {
            public static Resource resource = new Resource(); // This will be lazily initialised
        }
        public static Resource getResource() {
            return ResourceFactory.ResourceHolder.resource;
        }
        static class Resource {
        }
    }

class ResourceFactory {
      private volatile Resource resource;
      public Resource getResource() {
        Resource localResource = resource;
        if (localResource == null) {
          synchronized (this) {
            localResource = resource;
            if (localResource == null) {
              resource = localResource = new Resource();
            }
          }
        }
        return localResource;
      }
      static class Resource {
      }
    }

4.资源应该关闭

在使用后，**需要关闭实现Closeable接口或其超级接口AutoCloseable的连接，流，文件和其他类**。此外，必须在finally块中进行关闭调用，否则异常可能使调用无法进行。最好在类实现AutoCloseable时，应使用“ try-with-resources”模式创建资源并将其自动关闭。

无法正确关闭资源将导致资源泄漏，这可能首先导致应用程序崩溃，然后可能使应用程序崩溃。

**不兼容代码示例**

private void readTheFile() throws IOException {
      Path path = Paths.get(this.fileName);
      BufferedReader reader = Files.newBufferedReader(path, this.charset);
      // ...
      reader.close();  // 不合规
      // ...
      Files.lines("input.txt").forEach(System.out::println); // 不合规：需要关闭流
    }
    private void doSomething() {
      OutputStream stream = null;
      try {
        for (String property : propertyList) {
          stream = new FileOutputStream("myfile.txt");  // 不合规
          // ...
        }
      } catch (Exception e) {
        // ...
      } finally {
        stream.close();  //打开了多个流。仅最后一个关闭。
      }
    }

**兼容解决方案**

private void readTheFile(String fileName) throws IOException {
        Path path = Paths.get(fileName);
        try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
          reader.readLine();
          // ...
        }
        // ..
        try (Stream<String> input = Files.lines("input.txt"))  {
          input.forEach(System.out::println);
        }
    }
    private void doSomething() {
      OutputStream stream = null;
      try {
        stream = new FileOutputStream("myfile.txt");
        for (String property : propertyList) {
          // ...
        }
      } catch (Exception e) {
        // ...
      } finally {
        stream.close();
      }
    }

Java 7引入了try-with-resources语句，该语句隐式关闭Closeables。在try-with-resources语句中打开的所有资源都被该规则忽略。

4.“Random”对象应重复使用

每次需要一个随机值时，创建一个新的Random对象都是效率低下的，并且可能生成取决于JDK的非随机数。为了获得更好的效率和随机性，请创建一个随机数，然后存储并重新使用它。

Random()构造函数每次尝试为种子设置一个不同的值。但是，不能保证种子将是随机的，甚至是均匀分布的。一些JDK将当前时间用作种子，这使得生成的数字根本不是随机的。

该规则查找每次调用方法并将其分配给局部随机变量时都会创建新的Random的情况。

**不兼容代码示例**

public void doSomethingCommon() {
      Random rand = new Random();  // 不合规；每次调用都创建一个新实例
      int rValue = rand.nextInt();
      //...

**兼容解决方案**

private Random rand = SecureRandom.getInstanceStrong();  // SecureRandom优先于Random
    public void doSomethingCommon() {
      int rValue = this.rand.nextInt();
      //...

5.不再使用时应清除“ ThreadLocal”变量

一旦保持线程不再存在，就应该对ThreadLocal变量进行垃圾回收。当重新使用保持线程时，可能会发生内存泄漏，在使用线程池的应用程序服务器上就是这种情况。

为避免此类问题，建议始终使用remove（）方法清除ThreadLocal变量，以删除ThreadLocal变量的当前线程值。

另外，调用set（null）删除值可能会在映射中保留对该指针的引用，这在某些情况下可能导致内存泄漏。使用remove可以更安全地避免此问题。

**不兼容代码示例**

public class ThreadLocalUserSession implements UserSession {
      private static final ThreadLocal<UserSession> DELEGATE = new ThreadLocal<>();
      public UserSession get() {
        UserSession session = DELEGATE.get();
        if (session != null) {
          return session;
        }
        throw new UnauthorizedException("User is not authenticated");
      }
      public void set(UserSession session) {
        DELEGATE.set(session);
      }
       public void incorrectCleanup() {
         DELEGATE.set(null); // //不合规
       }
      // some other methods without a call to DELEGATE.remove()
    }

**兼容解决方案**

public class ThreadLocalUserSession implements UserSession {
      private static final ThreadLocal<UserSession> DELEGATE = new ThreadLocal<>();
      public UserSession get() {
        UserSession session = DELEGATE.get();
        if (session != null) {
          return session;
        }
        throw new UnauthorizedException("User is not authenticated");
      }
      public void set(UserSession session) {
        DELEGATE.set(session);
      }
      public void unload() {
        DELEGATE.remove(); // 合规
      }
      // ...
    }

6.字符串和包装类型应使用“equals()"进行比较

使用引用相等==或!=比较java.lang.String或包装类型（如java.lang.Integer）的两个实例几乎总是一个错误，因为它不是在比较实际值，而是在内存中的位置。

**不兼容代码示例**

String firstName = getFirstName(); // String overrides equals
    String lastName = getLastName();
    if (firstName == lastName) { ... }; //不合规；即使字符串具有相同的值，也为false

**兼容解决方案**

String firstName = getFirstName();
    String lastName = getLastName();
    if (firstName != null && firstName.equals(lastName)) { ... };

**在Java 中包装类型与基本数据类型存储位置不同。**

**Java 基本数据类型存放位置**

*  方法参数、局部变量存放在栈内存中的栈桢中的局部变量表
 *  常量存放在常量池中

**包装类型如Integer存放位置**

*  **常量池**
 *  **堆内存**

Integer 存储在常量池中时可以使用==对比，但当在堆内存中时，使用==对比，实际对比的是两个内存地址而非值。

根据Integer源码，

![format_png 1][]

可以看出数值在-128-127时，会使用cache中的数据，其实也就是常量池。超过范围后新创建Integer，此时数据就无法使用==。

**本项规则，主要就是为了避免对比内存地址而引发的错误判断。**

7.“ compareTo”不应重载

在实现Comparable.compareTo方法时，参数的类型必须与Comparable声明中使用的类型匹配。当使用其他类型时，这将创建一个重载而不是一个重写，这不太可能成为意图。

当实现Comparable的类的compareTo方法的参数与Comparable声明中使用的参数不同时，此规则会引起问题。

**不兼容代码示例**

public class Foo {
      static class Bar implements Comparable<Bar> {
        public int compareTo(Bar rhs) {
          return -1;
        }
      }
      static class FooBar extends Bar {
        public int compareTo(FooBar rhs) {  //不合规参数类型必须为Bar
          return 0;
        }
      }
    }

**兼容解决方案**

public class Foo {
      static class Bar implements Comparable<Bar> {
        public int compareTo(Bar rhs) {
          return -1;
        }
      }
      static class FooBar extends Bar {
        public int compareTo(Bar rhs) {
          return 0;
        }
      }
    }

8.周年("YYYY")不应用于日期格式

当使用SimpleDateFormat格式化和解析日期时，很少有开发人员会意识到“周年”的Y和“年”的y之间的区别。这很可能是因为对于大多数日期而言，“周年”和“年”是相同的，因此在除该年的第一周或最后一周之外的任何时间进行测试，都会得到y和Y相同的值。但是在12月的最后一周和 一月的第一周，您可能会得到意想不到的结果。

**不兼容代码示例**

Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
    String result = new SimpleDateFormat("YYYY/MM/dd").format(date);   //Noncompliant; yields '2016/12/31'

**兼容解决方案**

Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
    String result = new SimpleDateFormat("yyyy/MM/dd").format(date);   //Yields '2015/12/31' as expected

**异常**

Date date = new SimpleDateFormat("yyyy/MM/dd").parse("2015/12/31");
    String result = new SimpleDateFormat("YYYY-ww").format(date);  //compliant, 'Week year' is used along with 'W

9.装箱和拆箱不应连续操作

装箱是将原始值放入类似对象的过程，例如创建一个Integer来保存一个int值。拆箱是从此类对象中检索原始值的过程。

由于在装箱和拆箱期间原始值保持不变，因此在不需要时进行任何操作都是没有意义的。这也适用于自动装箱和自动拆箱（当Java为您隐式处理原始/对象转换时）。

**不兼容代码示例**

public void examineInt(int a) {
      //...
    }
    public void examineInteger(Integer a) {
      // ...
    }
    public void func() {
      int i = 0;
      Integer iger1 = Integer.valueOf(0);
      double d = 1.0;
      int dIntValue = new Double(d).intValue(); // Noncompliant
      examineInt(new Integer(i).intValue()); // Noncompliant; explicit box/unbox
      examineInt(Integer.valueOf(i));  // Noncompliant; boxed int will be auto-unboxed
      examineInteger(i); // Compliant; value is boxed but not then unboxed
      examineInteger(iger1.intValue()); // Noncompliant; unboxed int will be autoboxed
      Integer iger2 = new Integer(iger1); // Noncompliant; unnecessary unboxing, value can be reused
    }

**兼容解决方案**

10.Boxed "Boolean" should be avoided in boolean expressions

在布尔表达式中应避免使用装箱的“布尔”

如果将装箱的类型java.lang.Boolean用作表达式，则如Java语言规范§5.1.8取消装箱转换中所定义的，如果该值为null，则它将抛出NullPointerException。

完全避免这种转换并显式处理null值是更安全的。

**不兼容代码示例**

Boolean b = getBoolean();
    if (b) {  // Noncompliant, 当b为null，回抛NPE
      foo();
    } else {
      bar();
    }

**兼容解决方案**

Boolean b = getBoolean();
    if (Boolean.TRUE.equals(b)) { //注意这块写法
      foo();
    } else {
      bar();  // will be invoked for both b == false and b == null
    }

**微信公众号**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70][]

[format_png]: /images/20230529/4ae2ea6809ed46b9b89ca1f8ab0bb5f2.png
[format_png 1]: /images/20230529/c9fa51c289984fc8a147119136ee1780.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25pdWdhbmcwOTIw_size_16_color_FFFFFF_t_70]: /images/20230529/8071e9843fa84f35b5ee299f74bb23be.png