有些建议不太用到,但是用到的时候如果不注意就会进坑,所以书名改成Java的151个坑更合适。
-
不要在常量和变量中出现易混淆的字母
- 包名全小写,类名首字母全大写,常量全大写下划线分割,变量驼峰;
- 字母l作为长整形标志大写L;
-
莫让常量蜕变成变量
- 常量final staic,一般不会,主要是值常量的值不要通过计算获取值,值应该在编译期确认,不要在运行期更改;
-
三元操作符的类型务必一致
– 不一致会做转换,不管怎么转换,保持一致就行; -
避免带有变长参数的方法重载
- 重载的话,调用时不一定是你想要那个方法;
-
别让null值和空值威胁到变长方法
- 直接传递null或空值会让编译器区分不了调用的是哪个变长方法;
-
覆写变长方法也循规蹈矩
- 覆写满足的条件:
- 不能缩小访问权限;
- 参数列表与重写方法相同(类型、数量、显示形式);
- 返回类型相同或是其子类;
- 不能抛出新的异常或超出父类范围的异常,可以缩小或者不抛;
- 覆写变长方法参数列表必须完全一致;
- 覆写满足的条件:
-
警惕自增的陷阱
- java中count = count++等价于mockAdd(int count){int temp=count; count=count+1;return temp;};
- c++中count=count++会自增;
-
不要让旧语法困扰你
- 主要是java保有的一些关键字,如goto;
- 抛弃不用;
-
少用静态导入
- 不使用*通配符导入;
- 方法名是否具有明确清晰的意义;
- 感觉就是导入的常量类和常量一定要具有含义清晰,不能混淆;
-
不要在本类中覆盖静态导入的变量和方法
-
养成良好习惯,显示声明UID
- 实现Serializable接口的类,serialVersionUID要生成;
-
避免用序列化类在构造函数中为不变量赋值
- 序列化类中,不使用构造函数为final变量赋值;
- 基本类型,数组或简单对象(不通过new);
-
避免为final变量复杂赋值
- 反序列化时final变量在以下情况下不会被重新赋值:
- 通过构造函数赋值;
- 通过方法返回值赋值;
- final修饰的属性不是基本类型;
- 反序列化时final变量在以下情况下不会被重新赋值:
-
使用序列化类的私有方法巧妙解决部分属性持久化问题
- defaultWriteObject(),defaultReadObject(),writeXX和readXX屏蔽某些字段的序列化;
- 不要这个,基本不会用到;
-
break万万不可忘
-
易变业务使用脚本语言编写
- 之前工作中有个这样的需求,10几种类型根据公式计算不同生失效时间,公式易变,当时想用js,找了好久都没找到好用的,后来放弃了;
- 如果能找到适合的脚本engine,那就用吧;
-
慎用动态编译
-
避免instanceof非预期结果
- instanceof只能用于对象的判断,基本类型不行;
- 左操作数为null,直接返回false;
-
断言绝对不是鸡肋
- 在spring源码中n多使用断言的地方,感觉只是辅助注释的作用;
- 想用就用,不想用就算;
-
不要只替换一个类
- 如果你用ide的话,基本不会有这个问题;
- 发布时,禁止类文件替换,整体发布。常量类不要私自替换,因为常量会被预编译到引用的类中,会导致私自替换的不起作用;
-
用偶判断,不用奇判断
- 奇数判断,负数有问题
-
用整数类型处理货币
- 用什么整形,直接BigDecimal;
-
不要让类型默默转换
- 基本类型向包裹类型转换时,使用主动声明方式;
- long想Long转换:1L*X;
-
边界
- 单元测试时,边界测试要认真
-
四舍五入
- 第一次听说看见四舍五入还有这么多说法,服了,不过如果真有用到的地方一定要跟业务确认清楚;
- RoundingMode;
-
提防包装类型的null值
- 包装类型参入运算时,做null值校验;
-
谨慎包装类型的大小比较
- ==比较对象引用,>或<使用响应的value()方法;
- 使用相应的compareTo;
-
优先使用整形池
- valueOf生成的包装实例可以显著提供空间和时间性能;
- Integer和Long的会缓存-128到127之间的对象,范围外会new,Double和Float会new;
-
优先选择基本类型
- 基本类型可以先加宽,再转变成对应的包装类型,但是不能直接转变成宽的包装类型;
-
不要随机设置随机种子
- 随机数和种子的关系:
- 种子不同,产生不同的随机数;
- 种子相同,即使实例不同也产生相同的随机数;
- 非必要,不要设置种子;
- 随机数和种子的关系:
-
接口中不要存在实现代码
-
静态变量一定要先声明后赋值
- 变量赋值分2步:先分配空间后赋值,如果先赋值后声明的话,就可能后声明的赋值覆盖之前的赋值;
-
不要覆写静态方法
- 实例对象有2个类型:
- 表面类型:声明时的类型
- 和实际类型,对象产生时的类型
- 非静态方法根据实际类型来执行;
- 静态方法一般是通过类名访问,也可以通过对象访问,当通过对象调用静态方法时,会通过对象的表面类型查找入口执行,又是一个第一次听说的东西;
- 实例对象有2个类型:
-
构造函数尽量简化
-
避免在构造函数中初始化其他类
- 跟34对应,构造函数简化,然后提供其他初始化方法,spring中学会的;
-
使用构造代码块精炼程序
- 直接{}括起来的代码片段,会在每个构造函数中调用;
- 建议不要用;
-
构造代码块会想你所想
- 构造代码库在super,this调用的情况下也只会调用一次;
- 了解就行,非必要使用
-
使用静态内部类提供封装性
-
使用匿名类的构造函数
-
匿名类的构造函数很特殊
-
让多重继承称为现实
- 外部类继承一个,内部类再继承另一个;
-
让工具类不可实例化
- private 构造函数,阻止不了反射,实在不行就构造抛异常;
-
避免对象的浅拷贝
-
推荐使用序列化实现对象的拷贝
-
覆写equals方法时不要识别不出自己
- 对String做trim
- 这个要注意,好多接收外部数据什么的,都需要做trim处理;
-
equals应该考虑null值情景
- 判断null值情况
-
在equals中使用getClass进行类型判断
- 使用getClass进行类型判断,不要使用Instanceof,主要是防止继承情况下的判断;
- 这个还真没注意,下次要小心了;
-
覆写equals方法必须覆盖hashCode方法
-
推荐覆写toString方法
-
使用package-info类为包服务
- 很少用到,spring源码中看到,用这个给包做注释用的情况
- 作用:
- 声明友好类和保内访问常量;
- 为在包上标注注解提供便利;
- 包注释说明;
-
不要主动进行垃圾回收
-
推荐使用String直接量赋值
- 常量池;
-
注意方法传递的参数要求
- replaceAll传递的第一参数是正则,我去,真没在意这个,下次小心;
-
正确使用String,StringBuffer、StringBuilder
- 一般情况String,频繁操作后面2个,单线程StringBuilder,线程安全StringBuffer;
-
注意字符串的位置
- 加号表达式中,String字符串具有最高优先级;
- 对于运算符优先级有疑问的,直接括号省事;
-
自由选择字符串拼接方法
- 加号,concat或append,耗时依次减少;
-
推荐在复杂字符串操作中使用正则表达式
-
强烈建议使用UTF编码
- 编码是开发永远的噩梦;
-
对字符串排序持一种宽容的心态
- Collator中文排序,gb2312差不多可以解决,复杂的就找开源的或自己实现吧;
-
性能考虑,数组是首选
- 性能要求高的场景中使用数组替代集合;
-
若有必要,使用变长数组
- 主要是初始定长,后期校验扩容
-
警惕数组的浅拷贝
- Arrays.copyOf产生的是一个浅拷贝,基本类型拷贝值,其他拷贝引用地址;
-
场景明确下,为集合指定初始容量
-
多种最值算法,适时选择
- 自己实现;
- 先排序,后取值:Arrays.sort();
-
避开基本类型数组转换list陷阱
- 基本类型不能泛型话;
- Arrays.asList()参数不能使用原始类型;
-
asList产生的list对象不可更改
- 产生的list是一个静态内部类;
-
不能的列表选择不同的遍历方法
- ArrayList实现RandomAcess随机存取接口,使用for循环更好,而不是foreach;
-
频繁插入和删除使用LinkedList
- 对比ArrayList,想想数据结构就明白了;
-
列表相等只需关心元素数据
- 在AbstractList中实现元素和长度比较
-
子列表只是原列表的一个视图
- subList返回子列表;
- 所有对subList产生对象的操作作用于原list;
-
推荐使用subList处理局部列表
-
生成子列表后不要再操作原列表
- 会异常;
-
使用Comparator排序
-
不推荐使用binarySerach对列表进行检索
- 二分查找建立在基本有序的情况才行;
- 实现RandomAccess或数据量小于5K进行二分查找,否则顺序查找;
-
集合中元素必须做到compareTo和equals方法
-
集合运算时使用更优雅的方式
- 并集addAll
- 交集retainAll
- 差集removeAll
-
使用suffle打乱列表
- collections.shuffle();
-
减少hashmap中元素的数量
- 主要是扩容的时候,可能会内部不够用;
-
集合中hash码不要重复
- 不重复最好,重复也无所谓,不用关心;
-
多线程使用Vector或hashTable
-
非稳定排序推荐使用List
- treeset适用于不变量的数据集合排序;
- 在处理过程中可能会重新排序的,可以使用list自行排序;
-
集合家族
- list
- set
- map
- queue
- 数组
- 工具类:Arrays和反射类Array,collections
- 扩展类:commons和google的collections
-
推荐使用枚举定义常量
- 不太喜欢这种;
-
使用构造函数协助描述枚举项
-
使用枚举常量时,小心switch带来的空值异常
-
在switch的default代码块中增加AssertionError错误
- 如果使用枚举做switch就不应该走到default;
-
枚举使用valueOf前必须进行校验
-
枚举实现工厂模式
-
枚举项的数量限制在64个以内
-
小心注解继承
-
枚举和注解结合使用威力更大
- 注解的值可以使用枚举来定义;
-
注意@Override不同版本的区别
- 1.5版本的接口实现,不需要override,1.6以上没问题,注意下就可以;
-
java的泛型是类型擦除的
- 泛型参数编译后会被清除;
-
不能初始化泛型参数和数组
- 类型擦除,无法获取具体参数
-
强制声明泛型的实际类型
-
不同场景使用不同的泛型通配符
- 读操作? extend限定泛型上界;
- 写操作? super限定泛型下界;
-
警惕泛型是不能协变和逆变的
- 协变:窄类型替换宽类型;
- 逆变:宽类型替换窄类型;
-
建议采用的顺序是List\List
if(!method.isAccessible()){
method.setAccessible(true);
}
method.invoke(obj, args);
-
使用forName加载类文件
- 有个参数设置static方法是否调用,默认加载static代码块;
-
动态加载不适合数组
- 数组用的反射跟普通的不一样;
-
动态代码可以使代理模式更灵活
-
反射增加装饰模式的普适性
-
反射让模板方法模式更强大
-
不需要太多关注反射效率
- 如果有需求要用,就不要过分关注;
-
提倡异常封装
- 我们项目很少用,都是用封装errorcode,下次最起码保证自己的代码部分用到;
/** spring 中看到这种处理方式,感觉适合流程无关联性的业务*/
Class MyException extends Exception{
private List<Throwable> causes = new ArrayList<Throwable>();
public MyException(){
}
...get set ...
}
-
采用异常链传递异常
- 异常需要封装和传递,不同视角展示不同提示;
-
受检异常尽可能转为非受检异常
-
不要在finally块中处理返回值return
- finally返回会覆盖try块中的return值;
- 屏蔽异常;
- 只做收尾;
-
不要在构造函数中抛出异常
- 这个还真没见过这样处理的;
-
使用Throwable获得栈信息
-
异常只为异常服务
- 还真这么干过,正常业务有问题,为了省事直接抛出异常处理;
-
多使用异常,性能问题放一边
-
不推荐覆写start方法
- 不覆写Thread类的start方法
-
启动线程前stop方法是不可靠的
-
不适用stop方法停止线程
-
线程优先级只是用3个等级
- 差距大,才有体现;
-
使用线程异常处理器提升系统可靠性
123.volatile不能保证数据同步
-
异步运算考虑使用callable接口
- 有返回值和异常处理;
-
优先选择线程池
-
选择不同的线程池
-
Lock和synchronized是不一样的
-
预防死锁
-
适当设置队列长度
- 阻塞队列的长度是固定的;
-
countDownLatch协调子线程
- CountDownLatch、CyclicBarrier和Semaphore区别; -
CyclicBarrier让多线程齐步走
- 让多线程同时做某些事;
-
提升Java性能的基本方法
- 不要在循环条件中计算;
- 尽可能把变量、方法声明为final static类型;
- 缩小变量的作用范围;
- 频繁字符串操作使用StringBuffer或StringBuilder;
- 使用非线性检索;
- 覆写Exception的fillInStackTrace方法,耗时,看情况,没太多必要;
- 不建立冗余对象;
-
若非必要,不要克隆对象
- new做了优化;
-
推荐使用”望闻问切”的方式诊断性能
- 望:观察现象;
- 闻:团队的技术能力、氛围,习惯、擅长;
- 问:讨论;
- 切:分析问题;
-
定义性能衡量标准
-
解决首要系统性能问题
-
调整jvm参数提升性能
-
性能是个大“咕咚”
- 没有慢的系统,只有不满足业务的系统;
- 没有慢的系统,只有架构不良的系统;
- 没有慢的系统,只有懒惰的技术人员;
- 没有慢的系统,只有不愿意投入的系统;
- 怀疑精神;
-
大胆采用开源工具
-
推荐使用Guava扩展工具包
- 看情况吧,有需要,可以用,没有需求,就拉倒吧;
-
Apache扩展包
-
推荐使用Joda日期时间扩展包
-
可以选择多种Collections扩展
-
提倡良好的代码风格
- 见过几百行代码的方法,看的疯了;
-
不要完全依靠单元测试来发现问题
- 单元测试不可能测试所有场景:
- 正常场景;
- 边界场景;
- 异常场景;
- 单元测试没问题,可能全流程测试会出问题;
- 部分代码无测试,尤其是多线程环境的测试;
- 单元测试验证的是开发的想法,万一要是错的了,那不就挂了;
- 这个标题感觉改成不要相信测试最好,真实环境让你想吐;
- 单元测试不可能测试所有场景:
-
让注释正确、清晰、简洁
-
让接口的职责保持单一
-
增强类的可替换性
-
依赖抽象而不是实现
-
抛弃7条不良的编码习惯
- 自由风格的代码;
- 不适用抽象的代码;
- 彰显个性的代码;
- 死代码;
- 冗余代码;
- 自以为是的代码;
- 见过最差的,日志居然用sysout打印,想骂人的感觉;
-
以技术员自律而不是工人
- 不为工作,爱你的工作;
总结:
1. 刚开始看,不像是国人写的,老外倒是喜欢写这种类型的书,感谢作者;
2. 泛型和注解部分写的不错;
3. 书中的坑,好多都是你用到时一不小心就进去了,所以用你不常用东西时,一定要先了解下,这是看这本书最重要的体会了