• findbugs 错误分析


    findbugs 出错类型及对应解释
    1、Dead store to local variable 本地变量存储了闲置不用的对象
    举例:
    List accountCoList = new ArrayList();
    我们为accountCoList新建了一个对象,但是程序的后面并没有使用这个这个新建对象。
    建议改为:
    List accountCoList = null;

    2、Write to static field from instance method 向static字段中写入值
    举例:
    private static DBRBO dbrBO;
    public final void refresh() {
    danskeBankBO = null;
    dbrBO = null;
    fileAndPathBO = null;
    }
    建议改为:
    去掉static。
    3、Load of known null value 大体意思是加载了null的对象。
    举例
    if (null == boList) {

    for (int i = 0; i < boList.size(); i++) {
    entityList.add(productBOToEntity(boList.get(i)));
    }
    }
    4、Method ignores exceptional return value 没有对方法的异常返回值进行检查

    1.Call to equals() comparing different type

    大部分都是类型永远不会有这种情况 比如a为DOUBLE类型所以EQUALS只匹配字符串 if(a.equals())或if(a.quals())这类判断是根本不会有用的的
    2.Class doesn't override equals in superclass

    super.equals(obj) 调用父类equals方法 一般都是Object的方法,所以这个super可写可不写,一般都是 为了代码的可读性才加上去的
    一般就是重写equals(obj)即可 即public boolean equals(Object obj){ return super.equals(obj);}
    但是如果覆盖了equals()方法的话,则必须要覆盖hashCode()方法。否则FINDBUGS会出现下面的7号BUG:覆盖了equals()方法的话,则必须要覆盖hashCode()方法
    所以 public boolean equals(Object obj){ return super.equals(obj);}
    public int hashCode(){
    return super.hashCode();
    }

    3.Class is Serializable, but doesn't define serialVersionUID
    serialVersionUID 用来表明类的不同版本间的兼容性
    简单来说,Java的序列化机制是通过在运行时判断类的serialVersionUID来验证版本一致性的。在进行反序列化时,JVM会把传来的字节流中的serialVersionUID与本地 相应实体(类)的serialVersionUID进行比较,如果相同就认为是一致的,可以进行反序列化,否则就会出现序列化版本不一致的异常。
    当实现java.io.Serializable接口的实体(类)没有显式地定义一个名为serialVersionUID,类型为long的变量时,Java序列化机制会根据编译的class自动生成一个 serialVersionUID作序列化版本比较用,这种情况下,只有同一次编译生成的class才会生成相同的serialVersionUID 。
    如果我们不希望通过编译来强制划分软件版本,即实现序列化接口的实体能够兼容先前版本,未作更改的类,就需要显式地定义一个名为serialVersionUID,类型为long 的变量,不修改这个变量值的序列化实体都可以相互进行串行化和反串行化。
    也就是这个错误 你要定义一个名为 serialVersionUID,类型为long的变量 按照新版Eclipse自动填写规则 就是:
    private static final long serialVersionUID = 1L;
    4.Class names shouldn't shadow simple name of superclass
    嘛 基本就是这个类的名字跟超类的名字一样但不在一个包里 所以就改下类名啦
    5.Comparison of String parameter using == or !=
    原因:当比较两个字符串内容是否相同时,仅当两个字符串在源文件中都是常量时或者是使用intern()来比较才可以用==来比较,否则最好使用对象比较方法equal。附 string比较:
    String str1 = "java";
    String str2 = "java";
    System.out.print(str1==str2);
    结果:true(二者都为常量)
    String str1 = new String("java");
    String str2 = new String("java");
    System.out.print(str1==str2);
    结果:false(二者为对象)
    String str1 = "java";
    String str2 = "blog";
    String s = str1+str2;
    System.out.print(s=="javablog");
    结果:false(s不为常量,为对象)
    String s1 = "java";
    String s2 = new String("java");
    System.out.print(s1.intern()==s2.intern());
    结果:true(但是intern()方法在效率和实现方式上不统一)
    6.Call to equals() comparing different types
    equals比较了不同的对象类型 说的是equals要比较相同的对象类型
    7.Equals checks for noncompatible operand
    equals()方法比较的是值是否相同,而不是内存指向地址
    就实际情况来看 是因为
    public boolean equals(Object object) {
    if (!(object instanceof DmZzmm)) {
    return false;
    }
    Dxinfo rhs = (Dxinfo) object;
    return new EqualsBuilder().append(this.dxcount, rhs.dxcount).append(this.lxrsjh, rhs.lxrsjh)
    .append(this.dxnr, rhs.dxnr).append(this.fssj, rhs.fssj).append(this.fssl, rhs.fssl)
    .append(this.id,rhs.id).isEquals();
    。。。。
    }
    问题在那里?很简单 这个白痴是拷贝的代码 既然object 不为DmZzmm就为false 而你要执行的是 Dxinfo rhs = (Dxinfo) object; 所以 如果为DMZzmm进入代码 会因 为不是 Dxinfo 类型而不执行下面的代码 如果为Dxinfo 类型 它就直接执行为FALSE!!所以代码毫无意义 只会执行false!!
    所以只需要把
    public boolean equals(Object object) {
    if (object instanceof Dxinfo) {
    Dxinfo rhs = (Dxinfo) object;
    。。。。。。。
    }else{
    return false;
    }
    就可以了 说穿了 就是你准备用instanceof 匹配的类要跟你下面执行的类要一致。。。。
    8.equals method always returns false
    equals始终返回false
    嘛。。。就是没继承超类的话要自己写个EQUALS。。。。别写的没意义只有false就是了。。
    public boolean equals(Object o) {
    return (this==o);
    }
    9.equals() method does not check for null argument
    equals()方法没检查空参数
    10.Exception is caught when Exception is not thrown
    异常被捕获但没抛出。。。。
    一般人都会这样写代码:

      try{
        //
      }
      catch(Exception ex){
        //
      }
    这样很省事,但是JAVA规范中并不推荐这样做,这样是属于“过泛地捕获异常”,因为try{}中可能出现的异常种类有很多,上面的做法不利于分别处理各种异常,建议根 据业务需求,分别捕获需要特别处理的异常,例子如下:

      try{
        //
      }
      catch(SQLException ex){
        //
      }
      catch(IOException ex){
        //
      }
      catch(Exception ex){
        //
      }
    另外一个是,捕获到的Exception应尽量记录到LOG文件里。

    11.Field names should start with a lower case letter
    字段名应该用小写
    12.Can't close pw since it is always null
    无法关闭【PW】因为总是为NULL
    13.Non-transient non-serializable instance field in serializable class
    在可序列化的类中存在不能序列化或者不能暂存的数据
    14.May expose internal representation by incorporating reference to mutable object
    JAVA里,对象是引用传递的,setObj的时候,对象不要直接赋值(this.regDate = regDate),可改为:this.regDate = (Date)regDate.clone();,
    15.Method names should start with a lower case letter
    函数的首字母应该小写。
    16.Uninitialized read of field in constructor
    构造函数没有初始化;
    17.Method concatenates strings using + in a loop
    The method seems to be building a String using concatenation in a loop. In each iteration, the String is converted to a StringBuffer/StringBuilder, appended to, and converted back to a String. This can lead to a cost quadratic in the number of iterations, as the growing string is recopied in each iteration.
    Better performance can be obtained by using a StringBuffer (or StringBuilder in Java 1.5) explicitly.
    For example:
    // This is bad String s = ""; for (int i = 0; i < field.length; ++i) { s = s + field[i]; } // This is better StringBuffer buf = new StringBuffer(); for (int i = 0; i < field.length; ++i) { buf.append(field[i]); } String s = buf.toString();
    等待继续更新。。。。。。。。

    相关资料:
    1:hyddd的FindBugs分析记录
    http://www.cnblogs.com/hyddd/tag/hyddd%E7%9A%84FindBugs%E5%88%86%E6%9E%90%E8%AE%B0%E5%BD%95/

    2:FindBugs Bug Detector Report

    http://www.jquantlib.org/sites/jquantlib/findbugs.html

    3:FindBugs Bug Descriptions (推荐)

    http://findbugs.sourceforge.net/bugDescriptions.html#NP_NULL_PARAM_DEREF
    4.FindBugs缺陷类型统计分析:
    http://donsun.javaeye.com/blog/697407

  • 相关阅读:
    Intel的cpu虚拟化
    [转]深入理解Kingfisher(下)
    [转]深入理解Kingfisher(上)
    [转]Xcode中TimeProfile的使用
    [汇]编译错误汇总
    [汇]我常去逛的iOS干货文章、blog等
    [转]UICollectionView 全解
    [转]iOS 保持界面流畅的技巧
    [转]Swift 基于 willSet & didSet 的订阅block(Observable)
    IOS开发之UIScrollViewDelegate详解
  • 原文地址:https://www.cnblogs.com/duanxz/p/2734162.html
Copyright © 2020-2023  润新知