ARTS第十三周（閱讀Tomcat源碼）

1.Algorithm：每周至少做一個 leetcode 的算法題
2.Review：閱讀並點評至少一篇英文技術文章
3.Tip：學習至少一個技術技巧
4.Share：分享一篇有觀點和思考的技術文章

考研真難 , 卷的厲害 , 還能怎麼著 . 接着熬 , 繼續更新

以下是各項的情況：

Algorithm

鏈接：[LeetCode-442]-Find All Duplicates in an Array

題意：

給定一個鏈表: 1->2->3->4->5, 和 n = 2.

當刪除了倒數第二個節點後，鏈表變為 1->2->3->5.

分析：

以前做過一個類似題目 , 用hashmap 做一個對照詞典 , 有重複的就返回

class Solution {
    public int findRepeatNumber(int[] nums) {
          HashSet dictionary = new HashSet<Integer>();
          for (int num:nums){
            if(dictionary.contains(num)){
                return num;
            }
            dictionary.add(num);
          }
          
          return -1;
    }
}

　　照着做就完事

class Solution {
        public List<Integer> findDuplicates(int[] nums) {
            List<Integer> res = new ArrayList<>();

            if (nums == null || nums.length == 0) {
                return res;
            }

            // 一樣的hash
            for (int i = 0; i < nums.length; i++) {
                while (nums[nums[i] - 1] != nums[i]) {
                    swap(nums, i, nums[i] - 1);
                }
            }

            // 詞典記錄不重複
            for (int i = 0; i < nums.length; i++) {
                if (nums[i] != i + 1) {
                    res.add(nums[i]);
                }
            }
            return res;
        }

        public void swap(int[] arr, int index1, int index2) {
            int tmp = arr[index1];
            arr[index1] = arr[index2];
            arr[index2] = tmp;
        }
    }

Review

JDK17的新特性

很多歸納一下就是 :

始終嚴格的浮點語義、外部函數和內存 API 以及偽隨機數生成器的統一 API

功能包括 :

特定於上下文的反序列化過濾器支持 (允許應用程序通過調用 JVM 範圍的過濾器工廠來配置特定於上下文和動態選擇的反序列化過濾器)，這是一項安全增強 (反序列化過濾器被引入Java 9使應用程序和庫代碼能夠在反序列化之前驗證傳入的數據流。此代碼 java.io.ObjectInputFilter 在創建反序列化流時提供驗證邏輯。但是，依賴流的創建者來明確請求驗證有局限性。JDK Enhancement Proposal 290通過引入可通過 API、系統屬性或安全屬性設置的 JVM 範圍的反序列化過濾器解決了這些限制，但這種方法也有局限性，尤其是在複雜的應用程序中。更好的方法是配置每個流過濾器，這樣它們就不需要每個流創建者的參與。always-strict 浮點語義的恢復，浮點運算將變得始終嚴格)

模式匹配 switch 語句 ( switch 針對多個模式測試表達式和語句，每個模式都有特定的操作。引入兩種模式：guarded patterns，允許模式匹配邏輯用任意布爾表達式和 parenthesized patterns . 在JDK 16 中，instanceof 運算符被擴展為採用類型模式並執行模式匹配。提議的適度擴展允許簡化熟悉的 instanceof-and-cast 習語。)

刪除遠程方法調用 (RMI) 激活機制 (同時保留 RMI 的其餘部分。RMI 激活機制已過時和廢棄，在 JDK 15 中不推薦使用。)

增強的偽隨機數生成器將為偽隨機數生成器 ( PRNG ) 提供新的接口類型和實現，包括可跳轉的 PRNG 和額外的一類可拆分 PRNG 算法 ( LXM )。新接口 RandomGenerator 將為所有現有的和新的 PRNG 提供統一的 API。將提供四個專門的 RandomGenerator 接口。推動該計劃的重點是 Java 偽隨機數生成領域的多個改進領域。該計劃的目標包括：

使在應用程序中交替使用各種 PRNG 算法變得更容易。
改進了對基於流的編程的支持，提供了 PRNG 對象流。
消除現有 PRNG 類中的代碼重複。
保留類的現有行為 java.util.Random。

還有些其他的，就不翻譯了。

Tip

　　這幾天朋友問了個問題：請求一個網站很久超時，對應後台接口作用是導出大量數據的接口應用，請求導出一大批數據要執行很久，但是 http 等待到限制的時間後，鏈接就會斷開並顯示請求超時 , 而後台應用是一個子線程在處理，這時候這個子線程是隨着鏈接斷開而結束呢還是繼續做完未完成任務？（我瀏覽器請求後台服務，後台執行很長時間，但是瀏覽器請求超時了，這時候，後台服務還沒執行完，該子線程如何處理？繼續還是？）

　　我很快回答了：看策略，設定的失敗處理。同步就掛起等待，異步看你處理邏輯怎麼寫的。要寫銷毀就銷毀等待就掛起。

　　很快朋友就追問：那默認的 Tomcat 策略是什麼？R

　　這難倒我了，平常業務都是自己寫失敗處理。不過，要讓我們自己 @override 寫失敗處理，我猜默認的應該很辣雞，Tomcat 要是處理的好，就不會有 RocketMQ 用守護線程輪詢對應線程強制結束了。所以首先我先大膽猜：繼續執行，但是返回數據沒對應的接受，所以一般自己處理都會輪詢對應線程未響應直接銷毀，然後等下次響應。

不過猜的不算數，我想看看原本的策略是什麼？於是首先發現很有意思的問題現在用的 springboot，cloud 都是用 maven 或者 gradle ，都是集成了 Tomcat 的。那麼現在用的 maven 3.6 對應的 Tomcat 版本是多少？它的對應關係怎麼樣？ //tomcat.apache.org/whichversion.html 查詢