最近在工作的過程中，遇到了不少奇怪自己或者同事的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也會出現死迴圈的問題

本文來自博客園，作者：songtianer，轉載請註明原文鏈接：https://www.cnblogs.com/songjiyang/p/17582799.html