Java编程中容易忽略的10个问题
在Java编码中,我们容易犯一些错误,也容易疏忽一些问题,因此笔者对日常编码中曾遇到的一些经典情形归纳整理成文,以共同探讨。
1. 纠结的同名
现象
很多类的命名相同(例如:常见于异常、常量、日志等类),导致在import时,有时候张冠李戴,这种错误有时候很隐蔽。因为往往同名的类功能也类似,所以IDE不会提示warn。
解决
写完代码时,扫视下import部分,看看有没有不熟悉的。替换成正确导入后,要注意注释是否也作相应修改。
启示
命名尽量避开重复名,特别要避开与JDK中的类重名,否则容易导入错,同时存在大量重名类,在查找时,也需要更多的辨别时间。
2. 想当然的API
现象
有时候调用API时,会想当然的通过名字直接自信满满地调用,导致很惊讶的一些错误:
示例一:flag是true?
boolean flag = Boolean.getBoolean("true");
可能老是false。
示例二:这是去年的今天吗(今年是2012年,不考虑闰年)?结果还是2012年:
Calendar calendar = GregorianCalendar.getInstance();calendar.roll(Calendar.DAY_OF_YEAR, -365);
下面的才是去年:
calendar.add(Calendar.DAY_OF_YEAR, -365);
解决办法
问自己几个问题,这个方法我很熟悉吗?有没有类似的API? 区别是什么?就示例一而言,需要区别的如下:
Boolean.valueOf(b) VS Boolean.parseBoolean(b) VS Boolean.getBoolean(b);
启示
名字起的更详细点,注释更清楚点,不要不经了解、测试就想当然的用一些API,如果时间有限,用自己为熟悉的API。
3. 有时候溢出并不难
现象
有时候溢出并不难,虽然不常复现:
示例一:
long x=Integer.MAX_VALUE+1;System.out.println(x);
x是多少?竟然是-2147483648,明明加上1之后还是long的范围。类似的经常出现在时间计算:
数字1×数字2×数字3…
示例二:
在检查是否为正数的参数校验中,为了避免重载,选用参数number, 于是下面代码结果小于0,也是因为溢出导致:
Number i=Long.MAX_VALUE;
System.out.println(i.intValue()>0);
解决
让一开始的一个操作数是long型,例如加上L或者l(不建议小写字母l,因为和数字1太相似了);
不确定时,还是使用重载吧,即使用doubleValue(),当参数是BigDecimal参数时,也不能解决问题。启示
对数字运用要保持敏感:涉及数字计算就要考虑溢出;涉及除法就要考虑被除数是0;实在容纳不下了可以考虑BigDecimal之类。
4. 日志跑哪了?
现象
有时候觉得log都打了,怎么找不到?
示例一:没有stack trace!
} catch (Exception ex) { log.error(ex); }
示例二:找不到log!
} catch (ConfigurationException e) { e.printStackTrace();}
解决
替换成log.error(ex.getMessage(),ex);
换成普通的log4j吧,而不是System.out。
启示
API定义应该避免让人犯错,如果多加个重载的log.error(Exception)自然没有错误发生
在产品代码中,使用的一些方法要考虑是否有效,使用e.printStackTrace()要想下终端(Console)在哪。5. 遗忘的Volatile
现象
在DCL模式中,总是忘记加一个Volatile。
private static CacheImpl instance; //lose volatilepublic static CacheImpl getInstance() { if (instance == null) { synchronized (CacheImpl.class) { if (instance == null) { instance = new CacheImpl (); } } } return instance;}
解决
毋庸置疑,加上一个吧,synchronized 锁的是一块代码(整个方法或某个代码块),确保的是这”块“代码的可见性及原子性,但是instance == null次次判断时不再范围内的。所以可能读出的是过期的null。
启示
我们总是觉得某些低概率的事件很难发生,例如某个时间并发的可能性、某个异常抛出的可能性,所以不加控制,但是如果可以,还是按照前人的“实践”来写代码吧。至少不用过多解释为啥另辟蹊径。
6. 不要影响彼此
现象
在释放多个IO资源时,都会抛出IOException ,于是可能为了省事如此写:
public static void inputToOutput(InputStream is, OutputStream os, boolean isClose) throws IOException { BufferedInputStream bis = new BufferedInputStream(is, 1024); BufferedOutputStream bos = new BufferedOutputStream(os, 1024); …. if (isClose) { bos.close(); bis.close(); }}
假设bos关闭失败,bis还能关闭吗?当然不能!
解决办法
虽然抛出的是同一个异常,但是还是各自捕获各的为好。否则一开始的一个失败,后一个面就没有机会去释放资源了。
启示
代码/模块之间可能存在依赖,要充分识别对相互的依赖。
7. 用断言取代参数校验
现象
如题所提,作为防御式编程常用的方式:断言,写在产品代码中做参数校验等。例如:
private void send(List eventList) { assert eventList != null;}
网上报名
新闻资讯
更多>>-
新人程序员初入职职场,如何快速融入?
2017-03-29
-
JT16006—我们毕业啦!
2017-04-05
-
【教师风采】认真是一种态度!
2017-03-30
-
那些程序员们会念错的单词,你中枪了吗?
2017-03-31
-
【面试】那些程序员需要了解的面试技巧
2017-04-07