天天看點

後端開發必知的11個線程安全小技巧

作者:散文随風想

對于從事後端開發的同學來說,線程安全問題是我們每天都需要考慮的問題。

線程安全問題通俗地講主要是在多線程的環境下,不同線程同時讀和寫公共資源(臨界資源)導緻的資料異常問題。

比如:變量a=0,線程1給該變量+1,線程2也給該變量+1。此時,線程3擷取a的值有可能不是2,而是1。線程3這不就擷取了錯誤的資料?

線程安全問題會直接導緻資料異常,進而影響業務功能的正常使用,是以這個問題還是非常嚴重的。

那麼,如何解決線程安全問題呢?

今天跟大家一起聊聊,保證線程安全的11個小技巧,希望對你有所幫助。

一、無狀态

我們都知道隻有多個線程通路公共資源的時候,才可能出現資料安全問題,那麼如果我們沒有公共資源,是不是就沒有這個問題呢?

例如:

public class NoStatusService {
    public void add(String status) {
        System.out.println("add status:" + status);
    }

    public void update(String status) {
        System.out.println("update status:" + status);
    }
}           

這個例子中NoStatusService沒有定義公共資源,換句話說是無狀态的。

這種場景中,NoStatusService類肯定是線程安全的。

二、不可變

如果多個線程通路的公共資源是不可變的,也不會出現資料的安全性問題。

例如:

public class NoChangeService {
    public static final String DEFAULT_NAME = "abc";

    public void add(String status) {
        System.out.println(DEFAULT_NAME);
    }
}           

DEFAULT_NAME被定義成了static final的常量,在多線程中環境中不會被修改,是以這種情況也不會出現線程安全問題。

三、無修改權限

有時候,我們定義了公共資源,但是該資源隻暴露了讀取的權限,沒有暴露修改的權限,這樣也是線程安全的。

例如:

public class SafePublishService {
    private String name;

    public String getName() {
        return name;
    }

    public void add(String status) {
        System.out.println("add status:" + status);
    }
}           

這個例子中,沒有對外暴露修改name字段的入口,是以不存線上程安全問題。

四、synchronized

使用JDK内部提供的同步機制,這也是使用比較多的手段,分為同步方法和同步代碼塊。

我們優先使用同步代碼塊,因為同步方法的粒度是整個方法,範圍太大,相對來說,更消耗代碼的性能。

其實,每個對象内部都有一把鎖,隻有搶到那把鎖的線程,才被允許進入對應的代碼塊執行相應的代碼。

當代碼塊執行完之後,JVM底層會自動釋放那把鎖。

例如:

public class SyncService {
    private int age = 1;
    private Object object = new Object();

    //同步方法
    public synchronized void add(int i) {
        age = age + i;        
        System.out.println("age:" + age);
    }
    
    public void update(int i) {
        //同步代碼塊,對象鎖
        synchronized (object) {
            age = age + i;                     
            System.out.println("age:" + age);
        }    
     }
     
     public void update(int i) {
        //同步代碼塊,類鎖
        synchronized (SyncService.class) {
            age = age + i;                     
            System.out.println("age:" + age);
        }    
     }
}           

五、Lock

除了使用synchronized關鍵字實作同步功能之外,JDK還提供了Lock接口這種顯示鎖的方式。

通常我們會使用Lock接口的實作類:ReentrantLock,它包含了公平鎖、非公平鎖、可重入鎖、讀寫鎖等更多更強大的功能。

例如:

public class LockService {
    private ReentrantLock reentrantLock = new ReentrantLock();
    public int age = 1;
    
    public void add(int i) {
        try {
            reentrantLock.lock();
            age = age + i;           
            System.out.println("age:" + age);
        } finally {
            reentrantLock.unlock();        
        }    
   }
}           

但如果使用ReentrantLock,它也帶來了一個小問題,就是需要在finally代碼塊中手動釋放鎖。

不過說句實話,使用Lock顯示鎖的方式解決線程安全問題,給開發人員提供了更多的靈活性。

六、分布式鎖

如果是在單機的情況下,使用synchronized和Lock保證線程安全是沒有問題的。

但如果在分布式的環境中,即某個應用如果部署了多個節點,每一個節點使用可以synchronized和Lock保證線程安全,但不同的節點之間沒法保證線程安全。

這就需要使用分布式鎖了。

分布式鎖有很多種,比如:資料庫分布式鎖、zookeeper分布式鎖、redis分布式鎖等。

其中我個人更推薦使用redis分布式鎖,其效率相對來說更高一些。

使用redis分布式鎖的僞代碼如下:

try{
  String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
  if ("OK".equals(result)) {
      return true;
  }
  return false;
} finally {
    unlock(lockKey);
}             

同樣需要在finally代碼塊中釋放鎖。

七、volatile

有時候,我們有這樣的需求:如果在多個線程中,有任意一個線程,把某個開關的狀态設定為false,則整個功能停止。

簡單的需求分析之後發現:隻要求多個線程間的可見性,不要求原子性。

如果一個線程修改了狀态,其他的所有線程都能擷取到最新的狀态值。

這樣一分析這就好辦了,使用volatile就能快速滿足需求。

例如:

@Service
public CanalService {
    private volatile boolean running = false;
    private Thread thread;


    @Autowired
    private CanalConnector canalConnector;
    
    public void handle() {
        //連接配接canal
        while(running) {
           //業務處理
        }
    }
    
    public void start() {
       thread = new Thread(this::handle, "name");
       running = true;
       thread.start();
    }
    
    public void stop() {
       if(!running) {
          return;
       }
       running = false;
    }
}           

需要特别注意的地方是:volatile不能用于計數和統計等業務場景。因為volatile不能保證操作的原子性,可能會導緻資料異常。

八、ThreadLocal

除了上面幾種解決思路之外,JDK還提供了另外一種用空間換時間的新思路:ThreadLocal。

當然ThreadLocal并不能完全取代鎖,特别是在一些秒殺更新庫存中,必須使用鎖。

ThreadLocal的核心思想是共享變量在每個線程都有一個副本,每個線程操作的都是自己的副本,對另外的線程沒有影響。

溫馨提醒一下:我們平常在使用ThreadLocal時,如果使用完之後,一定要記得在finally代碼塊中,調用它的remove方法清空資料,不然可能會出現記憶體洩露問題。

例如:

public class ThreadLocalService {
    private ThreadLocal<Integer> threadLocal = new ThreadLocal<>();

    public void add(int i) {
        Integer integer = threadLocal.get();
        threadLocal.set(integer == null ? 0 : integer + i);
    }
}           

九、線程安全集合

有時候,我們需要使用的公共資源放在某個集合當中,比如:ArrayList、HashMap、HashSet等。

如果在多線程環境中,有線程往這些集合中寫資料,另外的線程從集合中讀資料,就可能會出現線程安全問題。

為了解決集合的線程安全問題,JDK專門給我們提供了能夠保證線程安全的集合。

比如:CopyOnWriteArrayList、ConcurrentHashMap、CopyOnWriteArraySet、ArrayBlockingQueue等。

例如:

public class HashMapTest {
    private static ConcurrentHashMap<String, Object> hashMap = new ConcurrentHashMap<>();

    public static void main(String[] args) {
        new Thread(new Runnable() {
            @Override
            public void run() {
                hashMap.put("key1", "value1");
            }
        }).start();

        new Thread(new Runnable() {
            @Override
            public void run() {
                hashMap.put("key2", "value2");
            }
        }).start();

      try {
            Thread.sleep(50);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(hashMap);
    }
}           

在JDK底層,或者spring架構當中,使用ConcurrentHashMap儲存加載配置參數的場景非常多。

比較出名的是spring的refresh方法中,會讀取配置檔案,把配置放到很多的ConcurrentHashMap緩存起來。

十、CAS

JDK除了使用鎖的機制解決多線程情況下資料安全問題之外,還提供了CAS機制。

這種機制是使用CPU中比較和交換指令的原子性,JDK裡面是通過Unsafe類實作的。

CAS内部包含了四個值:舊資料、期望資料、新資料和位址,比較舊資料和期望的資料,如果一樣的話,就把舊資料改成新資料。如果不一樣的話,目前線程不斷自旋,一直到成功為止。

不過,使用CAS保證線程安全,可能會出現ABA問題,需要使用AtomicStampedReference增加版本号解決。

其實,實際工作中很少直接使用Unsafe類的,一般用atomic包下面的類即可。

public class AtomicService {
    private AtomicInteger atomicInteger = new AtomicInteger();
    
    public int add(int i) {
        return atomicInteger.getAndAdd(i);
    }
}           

十一、資料隔離

有時候,我們在操作集合資料時,可以通過資料隔離,來保證線程安全。

例如:

public class ThreadPoolTest {
   public static void main(String[] args) {
      ExecutorService threadPool = new ThreadPoolExecutor(8, //corePoolSize線程池中核心線程數
      10, //maximumPoolSize 線程池中最大線程數
      60, //線程池中線程的最大空閑時間,超過這個時間空閑線程将被回收
      TimeUnit.SECONDS,//時間機關
      new ArrayBlockingQueue(500), //隊列
      new ThreadPoolExecutor.CallerRunsPolicy()); //拒絕政策

      List<User> userList = Lists.newArrayList(
      new User(1L, "蘇三", 18, "成都"),
      new User(2L, "蘇三說技術", 20, "四川"),
      new User(3L, "技術", 25, "雲南"));

      for (User user : userList) {
          threadPool.submit(new Work(user));
      }

      try {
          Thread.sleep(100);
      } catch (InterruptedException e) {
          e.printStackTrace();
      }
      System.out.println(userList);
  }

    static class Work implements Runnable {
        private User user;
        public Work(User user) {
            this.user = user;
        }
        @Override
        public void run() {
            user.setName(user.getName() + "測試");
        }
    }
}           

這個例子中,使用線程池處理使用者資訊。

每個使用者隻被線程池中的一個線程處理,不存在多個線程同時處理一個使用者的情況。是以這種人為的資料隔離機制,也能保證線程安全。

資料隔離還有另外一種場景:kafka生産者把同一個訂單的消息,發送到同一個partion中。每一個partion都部署一個消費者,在kafka消費者中,使用單線程接收消息,并且做業務處理。

這種場景下,從整體上看,不同的partion是用多線程處理資料的,但同一個partion則是用單線程處理的,是以也能解決線程安全問題。

繼續閱讀