常见Java缺陷模式

面对Java问题的定位-表现得不那么自信,有时我在想是我把问题想的太难,还是问题本身就难,还是我没有专心去看代码...,因为总总,有时还没有看到真正的问题,就阵亡啦,想来死得好冤呀。

本文属于《软件缺陷模式与测试》的读书摘要,感谢作者们辛苦写书,受益良多,书中对Java故障模式进行了总结,分6大类,对每个故障形成原因、表现形式进行分析,并给出了解决方案,值得细细阅读,去体会示例代码,相信读后再看到程序报错,会多那么点底气。

  1. 空指针
    日志:NullPointerException
    表现在:
  1. 可能为null的引用变量
    增加是否为null的判断
  2. 不完全的null条件判断
    判断逻辑不严谨,前面虽判断了是否为null,但是其他地方又用到该对象--修改判断逻辑
  3. 函数返回值可能为null
    list.getNext().dosomething() --list.getNext()为null
    使用返回值前 先做判断
  4. 函数返回值是数组类型时返回null
return new string[0]; 
改成 
return null;
  1. 所调用函数的参数约束为not null
if ( getClass() != obj.getClass() ) 
#如果obj为null,则抛出异常
  1. 重载equals 方法时没有处理好参数null的情况
    总结:获取到的对象有可能为null,在使用前最好先做判断,不为null,才做下一步。
  1. 数组越界
    基础知识:数组的下标index从(0--数组长度-1)
    即是:数组长度为2,数组两个值array_name[0]、array_name[1]
    任何index小于0,大于数组长度-1的-都会抛出数组越界
    日志:ArrayIndexOutOfBoundsException
    1)显示指定数组长度,数组使用越界
 public void arrayStudy(){
        int max_len = 4;
        int[] array = new int[max_len];
        for (int i=0; i<= max_len; i++){
            array[i] = i;   
        }
    }
#当array[4]时报
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 4
    at pers.qingqian.study.eight.ErrorStudy.arrayStudy(ErrorStudy.java:32)
    at pers.qingqian.study.eight.ErrorStudy.main(ErrorStudy.java:38)
  1. 隐式指定数组长度,数组使用越界
    public void arrayStudy(){
        int max_len = 4;
    //    int[] array = new int[max_len];
        int[] array = new int[]{1,2,3,4};
        for (int i=0; i<= max_len; i++){
            array[i] = i;
        }
    }

3)使用数组,length方法不当,数组使用越界
4)多维数组越界
总结:index只要在0-length-1内,不管是一维还是二维都不会有数组越界

  1. 资源泄漏
    基础知识:指的是封装了类似文件句柄、Socket、数据库连接、图形界面对象等这样的操作系统底层资源的对象被使用后,没有被显性的释放-及时将其回收。
  1. 函数内部资源泄漏
    public void printLines(String fName,Line lines){
      try{
           File file = new File(fName);
           PrintWriter pstr = new PrintWriter(new BufferedOutputStream(new FileOutputStream(file)));
          ... 省略N行代码
      }catch (IOException e){
            e.printStackTrace();
      }
     }
修改成
    public void printLines(String fName,Line lines){
        PrintWriter pstr = null;
      try{
           File file = new File(fName);
           pstr = new PrintWriter(new BufferedOutputStream(new FileOutputStream(file)));
            ... 省略N行代码
      }catch (IOException e){
            e.printStackTrace();
      }finally{
          pstr.close();
      }
     }

2)异常路径导致的资源泄漏

public void f() throws FileNotFoundException, IOException {
       FileOutputStream e = null;
       try {
           e = new FileOutputStream("C:\test.java");
           e.write(20);
           e.close();
       }
       finally {}// Defect
   }

当程序运行到e.write(20)抛出异常后,e.close()将不会被执行。
3)私有域资源不能释放导致泄漏
4)函数间调用产生的资源泄漏
简单的讲:A方法中中new了一个资源,没有写释放,直接将资源传递给B方法,B方法也没有是否该资源的地方
5)包装类构造方法出错可能造成资源泄漏
总结:不管出的现象怎么变,都是一个原因,创建了可和底层操作相关的对象时 就必须有释放该对象的方法,否则就会产生资源泄漏。
附:JDK库中资源分配和释放需要注意的问题

  1. 在JDK库中有一些修饰类-不是资源,但它们的构造方法中可能包装了一个资源。调用这些类的释放函数,也释放了内部包装的资源。
    2)不同的资源使用不同的释放函数close、dispose、disconnect
    3)不用资源具有不同的分配方式
    4)释放函数为close
FileOutputStream
FilterOutputStream
...
#这类最多

5)释放函数为dispose

StreamPrintService
CompositeContext
Graphics
InputContext
InputMethod
PaintContext
Window

6)释放函数为disconnect

HttpURLConnection

7)其他分配方式

getConnection
createStatement
executeQuery
getResultSet
prepareStatement
prepareCall
accept

8)可能被包装的非资源类

ByteArrayOutputStream

9)可能被包装的资源类

FileOutputStream
  1. 非法计算
  1. 除法或取余运算的第二个操作数可能为0
    2)常用的数学函数参数超出其定义范围
    如:asin(x) --- -1 <=x <=1
  1. 死循环
  1. 循环语句中的死循环结构
  2. while语句中的死循环结构
  3. do-while语句中的死循环结构
  4. 函数递归调用造成的死循环
    当真有死循环时非常容易发现的,只要访问到死循环代码,你就会发现CPU超级高,去看下线程就能找到是哪里死循环啦。
  1. 并发
    线程并发问题导致的缺陷模式
  1. 不正确的同步
  2. 死锁
  3. 多线程应用中方法调用时机或方式不正确
  4. 同一变量的双重验证
 public static Singleton getInstance(){
        if ( instance == null ){
            synchronized (Singleton.class) {
                if ( instance == null )
                    instance = new Singleton();                
            }           
        }
        return instance;
    }

线程1已运行到 instance = new Singleton(); ,被线程2抢占CPU,线程2运行 因instance不为null,返回对象。
由于instance已经被分配了内存空间,但没有初始化数据,因此利用线程2返回的instance做操作时会出现失败或异常。

  1. 相互初始化的类
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,189评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,577评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,857评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,703评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,705评论 5 366
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,620评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,995评论 3 396
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,656评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,898评论 1 298
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,639评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,720评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,395评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,982评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,953评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,195评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,907评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,472评论 2 342

推荐阅读更多精彩内容

  • 1. Java基础部分 基础部分的顺序:基本语法,类相关的语法,内部类的语法,继承相关的语法,异常的语法,线程的语...
    子非鱼_t_阅读 31,567评论 18 399
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,594评论 18 139
  • 对象的创建与销毁 Item 1: 使用static工厂方法,而不是构造函数创建对象:仅仅是创建对象的方法,并非Fa...
    孙小磊阅读 1,957评论 0 3
  • 从三月份找实习到现在,面了一些公司,挂了不少,但最终还是拿到小米、百度、阿里、京东、新浪、CVTE、乐视家的研发岗...
    时芥蓝阅读 42,174评论 11 349
  • 人生充满未知,以画思人!
    齔繪阅读 160评论 2 2