为什么说一个好的员工能顶 100 个普通员工
我们的做法是,要用最好的人。我一直都认为研发本身是很有创造性的,如果人不放松,或不够聪明,都很难做得好。你要找到最好的人,一个好的工程师不是顶10个,是顶100个。所以,在核心工程师上面,大家一定要不惜血本去找,千万不要想偷懒只用培养大学生的方法去做。最好的人本身有很强的驱动力,你只要把他放到他喜欢的事情上,让他自己有玩的心态,他才能真正做出一些事情,打动他自己,才能打动别人。所以你今天看到我们很多的工程师,他自己在边玩边创新。所以,找最好的人,要给他做他喜欢和擅长的事情。研发人员千万不要去管太严,一管就“死”了。工程师很讨厌跟规章制度打交道,作汇报他都很烦,大家不要管他,让用户去管他。他做好了一个产品,用户表扬他,这个大神多牛逼。他做不好了,用户骂他,他自己赶紧去改。
再谈阿里巴巴 Java 开发手册
之前在这个手册刚发布的时候看过一遍,当时感觉真是每个开发者都应该必读的一本手册,期间还写过一篇关于日志规约的文章:《下一个项目为什么要用 SLF4J》,最近由于在总结一些我们日常开发中容易忽略的问题,可能是最低级的编码常见问题,往往这也是最最容易忽略的,所以,又重新看了一遍这个手册,好像最近它也更新到了 1.2 版本。
这个手册目的就是让我们尽可能少踩坑,杜绝踩重复的坑。我接下来就打算试着写一些“坑”出来,来看看我们如何一不留神踩坑的,以及如何用正确的姿势跳出坑。
随随便便写出 NPE
首先声明一个 User
对象,接下来所有代码可能都会用到这个对象做演示,在下面将不在赘述。很简单,不上代码,上图片:
1.自动解箱抛 NPE
代码只有一行,再简单不过了:int method() { return new User().getId(); }
踩坑姿势:包装类型为 null 时,进行自动转换为基本数据类型报错。
解决方案:返回之前进行判断与处理或者改为相同类型。
2.级联调用易产生 NPE
这段代码有点容易迷惑人,因为它进行了集合元素的 isEmpty
判断,按说不会出问题了吧。看代码:
static void method1() {
List<User> list = new ArrayList<User>();
list.add(new User());
if (!CollectionUtils.isEmpty(list)) {
for (User user : list) {
System.out.println("userid:" + user.getId().toString());
}
}
}
不废话,看运行结果:
没错,还是报错了。
踩坑姿势:其实就是尽管你在之前做了对象不为空的判断,但你并不能保证对象中的值不为空,而且这时候去级联调用就会抛 NPE 。
手册中关于 NPE 的描述:
防止 NPE 是调用者的责任。即使被调用方法返回空集合或者空对象,对调用者来说,也并非高枕无忧,必须考虑到远程调用失败、序列化失败、运行时异常等场景返回 null 的情况。
集合里的元素即使 isEmpty,取出的数据元素也可能为 null。
级联调用 obj.getA().getB().getC();一连串调用,易产生 NPE
3.关于 Equals
这是日常开发中用于相等比较使用最多的方法了吧,因为当年谁没被 ==
坑过阿。现在一般我们都会这么写:user.getName().equals("mafly");
踩坑姿势: 一不小心使用了 null 值调用了 Equals
方法。
解决方案: 很简单咯,这么写:"mafly".equals(user.getName());
equals 方法容易抛空指针异常,应使用常量或确定有值的对象来调用 equals。
4.Map 下的 NPEMap
应该是我们开发中使用最频繁的了,最常用的可能有 HashMap
、ConcurrentHashMap
这俩了,可能会一不留神写出这样的代码:
踩坑姿势: 可能我们知道 ConcurrentHashMap
的 K/V 都不能为空,但我们有时候并不知道传进来的值是否为空。
解决方案: 设置时做下检验,对它的特性正确理解及使用。
由于 HashMap 的干扰,很多人认为 ConcurrentHashMap 是可以置入 null 值,而事实上,
存储 null 值时会抛出 NPE 异常
Map 类集合 K/V 能不能存储 null 值的情况,如下表格:
集合类 | Key | Value | Super | 说明 |
---|---|---|---|---|
Hashtable | 不允许为 null | 不允许为 null | Dictionary | 线程安全 |
ConcurrentHashMap | 不允许为 null | 不允许为 null | AbstractMap | 分段锁技术 |
TreeMap | 不允许为 null | 允许为 null | AbstractMap | 线程不安全 |
HashMap | 允许为 null | 允许为 null | AbstractMap | 线程不安全 |
简单聊聊常用的集合
5.foreach 遍历集合删除元素
大家应该都知道,在遍历集合时对元素进行 add/remove 操作要使用 Iterator,使用 for 循环时会报错,一定会报错吗?看代码:
public static void main(String[] args) {
List<String> a = new ArrayList<>();
a.add("1");
a.add("2");
a.add("3");
for (String temp : a) {
if ("2".equals(temp)) {
a.remove(temp);
}
}
Iterator<String> it = a.iterator();
while (it.hasNext()) {
String temp = it.next();
if ("2".equals(temp)) {
it.remove();
}
}
}
应该会报错的吧?因为在 for 循环中移出了元素,如果你运行了就会惊讶的,输出如下:
不解释其中原因了,感兴趣的可以看这篇文章:《foreach遍历list删除元素一定会报错?》。不管是不是倒数第二个元素才没问题,我们依然要注意不要在 foreach 循环里进行元素的 remove/add 操作。remove 元素请使用 Iterator 方式(代码第二种),如果并发操作,需要对 Iterator 对象加锁。
6.Arrays.asList() 数组转换集合
这个工具类应该都用过,可以很方便的把数组转换为集合,直接看结果吧:
踩坑姿势: Arrays.asList()
把数组转换成集合时,不能使用其修改集合相关的方法,它的 add/remove/clear 方法会抛出 UnsupportedOperationException
异常。 asList()
的返回对象是一个 Arrays 内部类,并没有实现集合的修改方法。
解决方案: 在转换之前操作咯。还需要注意一点,在你转换后,再对数组的值进行修改时,集合也会跟着变哦(注释掉的代码)。
7. toArray() 集合转换数组
当我们需要把一个集合转换为数组时,往往会调用 toArray()
方法,如果你用的是无参的这个可以吗?
当然不可以啦!会报 ClassCastException
异常。
踩坑姿势: 直接使用 toArray()
无参方法返回值只能是 Object[]类,若强转其它类型数组将会抛异常。
解决方案: 使用 <T> T[] toArray(T[] a);
有参数这个方法,代码如下:
String[] array = new String[list.size()];
array = list.toArray(array);
8. subList 的使用
集合中的 subList
是用于来返回某一部分的视图内容的,可能我们不是很常用,但是其中有好多坑的,直接看代码:
这次我们从输出来看上面的所有关于 subList
的代码。
- 18行: 当你原始集合大小没有那么大时,毫无疑问抛异常。
- 20-21行:得到一个新的集合,我们往新集合中增加一条数据。
- 23-26行:遍历原始集合,竟然
size=2
了,而且往新集合中增加的数据存在与原始集合。 - 28-31行:移除新集合中一条数据,遍历新集合。
- 33-37行:原始集合增加一条数据并遍历。
- 40-42行:遍历新集合,抛出
ConcurrentModificationException
异常。
从上述代码中,我们应该可以得出如下结论:返回的新集合是靠原来的集合支持的,修改都会影响到彼此对方。在 subList 场景中,高度注意对原集合元素个数的修改,会导致子列表的遍历、增加、删除均产生异常。
先总结一下
写到这只是其中关于异常部分的一些坑吧,还有另外一些令人异常惊讶的“我的天吶”的问题,由于篇幅太长了点,感觉不能再写下去了,过两天再接着写吧。
异常真的是一个有意思的问题。