小编点评

1. **类型擦除：**由于你使用泛型没有指定泛型类型，编译器无法确定变量`nameToType`的类型，导致类型擦除。 2. **`null`值：**当你将`null`插入`HashMap`中，会引发 `NullPointerException`，因为`HashMap`不允许存储`null`值。 3. **`ConcurrentModificationException`：**在使用`stream.filter`和`collect`操作过程中，如果数据集非常大，可能会导致`ConcurrentModificationException`。 4. **循环死循环：**在使用`for`循环删除`delIndex`中的元素时，如果数据集比较大，可能会导致循环死循环。 5. **`HashMap`并发问题：**由于`HashMap`是并发操作的，使用多个线程来添加元素可能会引发`ConcurrentModificationException`。 6. **`HashMap`死循环：**在使用`for`循环遍历`HashMap`时，如果数据量很大，可能导致`HashMap`死循环。

正文

最近在工作的过程中，遇到了不少奇怪自己或者同事的Bug，都是一些出乎意料的，不太容易发现的，记录一下来帮助可能也遇到了这些Bug的人

1. 编译时泛型校验失效

Map<String, String> nameToType = new HashMap<>();
nameToType.put( "testName", 123 ); // java: 不兼容的类型: int无法转换为java.lang.String

上面的代码，我们很容易看出来，无法通过编译，因为Map的value需要的是一个String，但我们传的是一个int。但我只要稍微改一下：

package generic;

import java.util.HashMap;
import java.util.Map;

public class RecContext<T>{

	private Map<String, String> nameToType = new HashMap<>();

	public Map<String, String> getNameToType(){

		return nameToType;
	}

	public void setNameToType( Map<String, String> nameToType ){

		this.nameToType = nameToType;
	}

	public static void main( String[] args ){

		RecContext recContextRaw = new RecContext();
		recContextRaw.getNameToType().put( "testName", 123 );

	}
}

同样是一个value要求为String的Map, 放到一个对象里面就可以通过编译了

不过这不是一个普通的对象，这个Class本身带泛型，但我们在使用的时候，没有指定这个泛型，也就是IDEA中常常报的错，说你在Raw Use这个类型

也正是因为Raw Use了这个类，所以导致它的泛型属性也被类型擦除了，具体可以看StackOverflow-What is a raw type and why shouldn't we use it?

这篇文章里面是这么说的

In simpler terms, when a raw type is used, the constructors, instance methods and non-static fields are also erased

简单地讲，当使用了原始类型，构造器、实例方法和非静态的字段都会被擦除

我们有一个老的项目里面有不少这样的Raw use，也正好有另外一个同事把一个其他的类型插入了这个Map，于是就报了一个类型转换错误，同事们都很震惊，认为这个Map不是有泛型吗，怎么可能插入别的类型，一番排查，才发现是这个问题

解决方法

1. 不要Raw use类，会使编译校验失效，也有很多其他的理由，可以参考上面那篇文章，我不使用的原因是因为IDEA每次都会发出告警。还有如果发现这个类一直在Raw use也没啥问题，说明这个类本身就不需要泛型，可以考虑是一下是不是需要重构一下

• 我的告警配置的是黄色的背景，看起来很惹眼
• IDEA的告警会是Raw use，不可能的条件判断，可以更换写法的代码（完全不影响效果），甚至可能是bug（之前碰到过，修复的时候发现IDEA已经提示了，但是可能别人的告警不是很明显，没看到）

2. 如果是真的Raw use了类，那检查类型是否错误的责任就落到我们自己的头上，确保不要传进错误的类型，确保取出来的类型不要转换错误

2. 数组删除中的“刻舟求剑”

线上代码中有这样一个逻辑，想从帖子列表中筛选出一部分帖子然后从原列表中删除，其代码逻辑如下：

import java.util.ArrayList;
import java.util.List;

public class ListDelTest{

	public static void main( String[] args ){

		List<Integer> jobIds = new ArrayList<>();
		for( int i = 0; i < 10; i++ ){
			jobIds.add( i );
		}

		List<Integer> delIndex = new ArrayList<>();
		for( int i = 0; i < jobIds.size(); i++ ){

			// 线上是其他的筛选逻辑，在这我们用偶数代替
			if( jobIds.get( i ) % 2 == 0 ){

				delIndex.add( i );
			}
		}

		for( int i = 0; i < jobIds.size(); i++ ){
			if( delIndex.contains( i ) ){
				jobIds.remove( jobIds.get( i ) );
			}
		}

		System.out.println( jobIds );
		// [1, 2, 4, 5, 7, 8]
	}
}

可以看到输出结果中，并不符合我们的预期，我们希望的是把所有的偶数删除，结果中不但有偶数，而且一些奇数也不见了

这个其实很容易理解，因为我们记得位置是0,2,4,6,8

原始数据是0,1,2,3,4,5,6,7,8,9
当我们删除了0时，数据变成了1,2,3,4,5,6,7,8,9

这时候我们再去删除index是2的值，结果就把3这个值给删除了

解决方法

1. 使用stream filter collect，这种其实不是原地删除，而是新建了一个List, 不过我们把这个List覆盖原来的引用，效果一样
2. 常见的边遍历边删除的方法，使用Iterator，可以避免ConcurrentModificationException异常

		int i = 0;
		Iterator<Integer> iterator = jobIds.iterator();
		while( iterator.hasNext() ){
			iterator.next();
			if( delIndex.contains( i ) ){
				iterator.remove();
			}
			i++;
		}

		System.out.println( jobIds );
		// [1, 3, 5, 7, 9]

3. 倒着删除，这样不会影响我们已经记录过的index，我记得当时我在华为OD面试的时候一个面试官问的我的一个问题，我没答出来，他告诉我的答案

		for( int i = jobIds.size() - 1; i > -1; i-- ){
			if( delIndex.contains( i ) ){
				jobIds.remove( jobIds.get( i ) );
			}
		}

3. Java8 HashMap死循环

线上同事上线了一个新的过滤器，我们的过滤器是并发执行的，比如，帖子敏感词过滤，会将帖子分成10份，用10个线程分别执行，执行完了就把结果放到一个公共的map中

很明显，这个map是有线程安全问题的，因为会有多个线程同时去put，然而，因为没考虑到，同事使用了普通的HashMap

线上的现象就是，每过一段时间，某个机器的CPU使用率就到了90%以上，需要重启

按照我们的理解，就算是有并发问题，怎么会使CPU使用变高呢

我们都背过，在Java1.7中的HashMap会因为并发插入产生死循，1.8使用尾插法代替头插法解决了死循环

可我们用的是Java1.8，看起来好像还是有死循环的问题

具体原因我就不仔细分析了，是在链表转换树或者对树进行操作的时候会出现线程安全的问题

可以参考HashMap在jdk1.8也会出现死循环的问题

解决方法

1. 多线程还是需要使用ConcurrentHashMap

参考

[1] StackOverflow-What is a raw type and why shouldn't we use it?

[2] HashMap在jdk1.8也会出现死循环的问题