开发经验教训

 

（1）内存泄漏

录像下载用C写的，手动 malloc  申请了内存。但全文只在程序正常结束return 0 前进行了free，所有异常退出的地方竟然都没有free！导致内存泄漏。

（2）点进行方法调用，一定要进行对象非空判断

alrmMap.get("longitude")
public static String toStr(Object obj){
    return null == obj ? "" : obj.toString();
}

1.alrmMap如果为null，点get就会报空指针异常，程序直接崩掉。

2.如果alrmMap.get("longitude")作为一个入参传递给另外一个方法，还要对get的返回值进行判断，如果为null要转为空字符串"" 

3.调第三方的http接口获得的返回数据时也要进行异常判断，null判断。

看到这么多异常，想要找出我们常见的5中运行时异常是非常容易的。  

例如：

ClassCastException(类转换异常)

IndexOutOfBoundsException(数组越界异常)

NullPointerException(空指针异常)

ArrayStoreException(数据存储异常，操作数组时类型不一致)

BufferOverflowException(还有IO操作的,缓冲溢出异常)

try{

} catch (Exception|Error e) {
    throw new ErrorException(ErrorCodeMarket.MAP_CODE_0001, ErrorCodeMarket.MAP_MSG_0001);
}

（3）类中定义static静态变量要慎重

一定要仔细思考下，此变量是否一定要定义成静态的！

static关键字的特点

1.一个类中被static所修饰的成员被类的所有对象共享。

2. 随着类的加载而加载，所有优先于对象的存在

3.可以通过类名调用

static注意事项：
1.在静态方法中是没有this关键字的
静态是随着类的加载而加载，this是随着对象的创建而存在。
静态比对象先存在。

2.静态方法只能访问静态的成员变量和静态的成员方法
静态只能访问静态,非静态可以访问静态的也可以访问非静态的。

（4）尽量不用e.printStackTrace

Java开发之log日志的使用尽量不用e.printStackTrace

http://baijiahao.baidu.com/s?id=1639733404613101605&wfr=spider&for=pc

前言

在Java开发中，无论是运行还是调试，一般都会对异常进行处理，一则明确问题出在哪个地方，一则也是代码完整性的一部分。谈到log日志，小编建议初学java的朋友使用框架集成的log4j、logback这类统一打印日志，尽量不使用catch的e.printStackTrace()，为什么呢？下面我们来做简单介绍。

为什么尽量不用e.printStackTrace

直接用e.printStackTrace来打印日志有错吗？当然不错，但是不好。主要原因有以下几点：

1、占用太多内存，造成锁死

要打印字符串输出到控制台上，需要字符串常量池所在的内存块有足够的空间。然而，因为e.printStackTrace() 语句要产生的字符串记录的是堆栈信息，太长太多，内存被填满了！大量线程产出字符串产出到一半，等待有内存被释放，锁死了，导致整个应用挂掉了。

2、日志交错混合，不易读

从开始学习java，老师就教我们写代码要具有可读性，易读性。同样，日志的输出如果不具有易读性，也是让程序员非常头疼的一件事。那么为什么e.printStackTrace输出的日志具有不易读性了呢？

printStackTrace()默认使用了System.err输出流进行输出，与System.out是两个不同的输出流，那么在打印时自然就形成了交叉。再就是输出流是有缓冲区的，所以对于什么时候具体输出也形成了随机。