專欄簡介

61.HTTPS 在防御重放攻擊中的作用與局限性

HTTPS 通過 SSL/TLS 協(xié)議為 HTTP 通信提供了強大的傳輸層安全保障，確保了數(shù)據(jù)的機密性（通過加密）和完整性（通過消息認證碼）。然而，HTTPS 協(xié)議本身并不能直接防御重放攻擊。重放攻擊指的是攻擊者截獲合法的通信報文，并在稍后重新發(fā)送這些報文，試圖欺騙接收方（通常是服務(wù)器）執(zhí)行重復(fù)或非預(yù)期的操作。即使報文是加密的，其重放仍然可能導(dǎo)致問題。

要有效抵御重放攻擊，需要在 HTTPS 傳輸層之上或協(xié)議內(nèi)部（如 TLS 握手）實現(xiàn)額外的應(yīng)用層或協(xié)議層機制。常見的策略包括：

1. 時間戳（Timestamping）： 在請求中加入當(dāng)前時間戳，服務(wù)器校驗時間戳是否在可接受的短暫窗口內(nèi)，過時或未來的時間戳將被拒絕。
2. 序列號（Sequence Numbers）或 Nonce（一次性隨機數(shù)）： 為每個請求或會話分配唯一的、遞增的序列號或不可預(yù)測的隨機數(shù)。服務(wù)器記錄已處理的序列號/Nonce，拒絕重復(fù)的請求。TLS 協(xié)議的握手過程就內(nèi)建了使用隨機數(shù)來防止握手階段的重放。
3. 一次性令牌（One-time Tokens）： 服務(wù)器為特定操作生成一次性使用的令牌，客戶端在請求時必須攜帶此令牌，使用后即失效。

因此，雖然 HTTPS 提供了安全的通信通道，但防止重放攻擊需要依賴于在通信協(xié)議或應(yīng)用程序邏輯中實施上述策略?，F(xiàn)代安全實踐，如 OAuth 等授權(quán)框架，也通常包含防止重放的機制。

62.Java List 移除元素后的索引與元素位移機制

在 Java 中，當(dāng)從 List（特別是像 ArrayList 這樣基于數(shù)組實現(xiàn)的 List）中移除一個元素時，其后的所有元素確實會向前移動以填補被移除元素留下的位置。這個過程確保了列表內(nèi)部存儲的連續(xù)性，并會更新受影響元素的索引。

具體來說，如果移除了索引為 i 的元素，那么原來索引為 i+1 的元素會移動到索引 i，原來索引為 i+2 的元素會移動到索引 i+1，以此類推，直到列表的末尾。這個操作的成本與列表中被移動元素的數(shù)量成正比。例如，從包含 [A, B, C, D] 的 ArrayList 中移除第一個元素 A（索引 0），列表會變?yōu)?[B, C, D]，其中 B 的索引變?yōu)?0，C 的索引變?yōu)?1，D 的索引變?yōu)?2。需要注意的是，對于基于鏈表實現(xiàn)的 List（如 LinkedList），移除元素主要是指針操作，不涉及大規(guī)模的元素物理移動，但索引邏輯仍然需要調(diào)整。

63.理解 Java HashMap 的初始化容量、負載因子與擴容機制

在 Java 中執(zhí)行 HashMap map = new HashMap(50); 這行代碼時，是在創(chuàng)建一個 HashMap 實例并指定其初始容量。這個操作本身并不會觸發(fā)任何擴容。HashMap 內(nèi)部會根據(jù)你提供的初始容量（50）來確定一個實際的內(nèi)部數(shù)組大小。為了優(yōu)化哈希計算，這個內(nèi)部數(shù)組的大小總是會被調(diào)整為大于或等于指定初始容量的、最接近的 2 的次冪。因此，對于 new HashMap(50)，實際的初始容量會被設(shè)置為 64。

HashMap 的擴容操作發(fā)生在其存儲的鍵值對數(shù)量（size）超過了一個特定的**閾值（threshold）時。這個閾值由當(dāng)前容量（capacity）乘以負載因子（load factor）**計算得出，即 threshold = capacity * loadFactor。HashMap 的默認負載因子是 0.75，這是一個在空間利用率和查找時間之間取得平衡的經(jīng)驗值。

因此，對于一個初始容量為 32 的 HashMap，其默認閾值是 32 * 0.75 = 24。當(dāng)你要插入第 25 個元素時（即 size 從 24 變?yōu)?25），就會觸發(fā)擴容。擴容是一個相對耗時的操作，它會創(chuàng)建一個新的、通常是原容量兩倍的內(nèi)部數(shù)組，并重新計算所有現(xiàn)有元素的哈希值，將它們放入新數(shù)組的適當(dāng)位置（rehashing）。為了避免頻繁擴容帶來的性能開銷，如果能預(yù)估存儲元素的數(shù)量，建議在創(chuàng)建 HashMap 時指定一個足夠大的初始容量。

64.識別無法保證每趟排序至少確定一個元素最終位置的排序算法

并非所有排序算法都能保證在每一趟處理后，至少將一個元素放置到其最終排序后的正確位置。典型的例子包括希爾排序（Shell Sort）和插入排序（Insertion Sort）。

希爾排序通過將列表按特定間隔（gap）分組，并對每個子組進行插入排序。在初始的幾趟排序中，間隔較大，元素在其子組內(nèi)有序并不意味著它在整個列表中的位置是最終的。隨著間隔逐漸縮小，排序逐漸趨于全局有序，但早期階段的排序無法保證任何元素已達到其最終位置。

插入排序在每一趟中將當(dāng)前元素插入到其左側(cè)已排序序列的合適位置。雖然保證了當(dāng)前處理元素在其左側(cè)子序列中的相對順序是正確的，但這并不意味著該位置是它在整個列表完全排序后的最終位置。后續(xù)元素的插入可能會導(dǎo)致已排序部分的元素再次移動。相比之下，像選擇排序（每趟找到最小/大元素放到起始/末尾）或冒泡排序（每趟將最大/小元素“冒泡”到末尾/起始）則能保證每趟至少確定一個元素的最終位置。

65.阻塞與非阻塞網(wǎng)絡(luò) I/O 的差異及適用場景分析

阻塞（Blocking）I/O 和非阻塞（Non-blocking）I/O 是網(wǎng)絡(luò)編程中處理數(shù)據(jù)交換的兩種核心模式，它們的主要區(qū)別在于應(yīng)用程序在等待 I/O 操作完成時的行為。

阻塞 I/O 模式下，當(dāng)應(yīng)用程序發(fā)起一個 I/O 操作（如 read 或 write）時，如果數(shù)據(jù)尚未準備好或無法立即完成，應(yīng)用程序的執(zhí)行線程會被掛起（阻塞），直到操作成功完成或出錯。在此期間，該線程無法執(zhí)行其他任務(wù)。這種模式編程模型相對簡單直接，適用于并發(fā)連接數(shù)不高、或者可以通過多線程/多進程模型為每個連接分配獨立處理單元的應(yīng)用場景，這樣單個連接的阻塞不會影響其他連接的處理。

非阻塞 I/O 模式下，應(yīng)用程序發(fā)起 I/O 操作時，調(diào)用會立即返回，而不會使線程掛起。如果操作因數(shù)據(jù)未就緒等原因無法立即完成，系統(tǒng)會返回一個特定狀態(tài)（如錯誤碼 EWOULDBLOCK 或 EAGAIN）。應(yīng)用程序需要通過輪詢或結(jié)合事件通知機制（如 select, poll, epoll, kqueue）來檢查 I/O 操作是否就緒，并在就緒時再次嘗試操作。這種模式允許單個線程管理多個 I/O 通道，極大地提高了系統(tǒng)資源的利用率，特別適用于需要處理大量并發(fā)連接的高性能服務(wù)器（如 Web 服務(wù)器、消息隊列、數(shù)據(jù)庫代理），以及需要保持高響應(yīng)性的實時應(yīng)用（如游戲服務(wù)器、在線交易系統(tǒng)）等 I/O 密集型場景。

總的來說，阻塞 I/O 以簡單性換取了潛在的性能瓶頸，而非阻塞 I/O 通過更復(fù)雜的編程模型實現(xiàn)了更高的并發(fā)處理能力和系統(tǒng)效率。現(xiàn)代高性能網(wǎng)絡(luò)應(yīng)用普遍采用非阻塞 I/O 結(jié)合事件驅(qū)動的架構(gòu)。

66.使用 wait()/notifyAll() 實現(xiàn) Java 線程按序執(zhí)行

在多線程編程中，有時需要控制線程的執(zhí)行順序，例如確保線程 T1 執(zhí)行完畢后 T2 再執(zhí)行，T2 執(zhí)行完畢后 T3 再執(zhí)行。Java 的 wait(), notify(), 和 notifyAll() 方法，結(jié)合 synchronized 關(guān)鍵字，提供了一種實現(xiàn)這種順序控制的機制。

該方法的核心是利用一個共享對象鎖（lock）和一個共享狀態(tài)變量（例如 turn）來協(xié)調(diào)線程。每個線程在執(zhí)行其核心邏輯前，首先獲取共享對象的鎖。然后，它檢查共享狀態(tài)變量是否指示輪到自己執(zhí)行。如果不是，線程調(diào)用 lock.wait()，暫時釋放鎖并進入等待狀態(tài)。如果是自己的回合，線程執(zhí)行其任務(wù)，然后更新共享狀態(tài)變量（例如 turn++），以指示下一個線程可以執(zhí)行。最后，該線程調(diào)用 lock.notifyAll() 來喚醒所有在該鎖上等待的其他線程。被喚醒的線程會重新嘗試獲取鎖，并再次檢查執(zhí)行條件。

下面是使用 wait()/notifyAll() 實現(xiàn)三個線程按 T1->T2->T3 順序執(zhí)行的示例代碼：

public class SequentialExecution {
    private static final Object lock = new Object();
    private static int turn = 1; // 控制哪個線程該執(zhí)行

    public static void main(String[] args) {
        new Thread(new Task(1), "T1").start();
        new Thread(new Task(2), "T2").start();
        new Thread(new Task(3), "T3").start();
    }

    static class Task implements Runnable {
        private final int threadId;

        public Task(int threadId) { this.threadId = threadId; }

        @Override
        public void run() {
            synchronized (lock) {
                try {
                    // 如果不是當(dāng)前線程的回合，則等待
                    while (turn != this.threadId) {
                        lock.wait();
                    }
                    // 執(zhí)行任務(wù)
                    System.out.println(Thread.currentThread().getName() + " is running");
                    // 更新狀態(tài)，輪到下一個線程
                    turn++;
                    // 喚醒所有等待的線程，讓它們檢查條件
                    lock.notifyAll();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt(); // 重置中斷狀態(tài)
                    System.err.println("Thread interrupted: " + e.getMessage());
                }
            }
        }
    }
}

這種方法雖然能實現(xiàn)順序控制，但在復(fù)雜場景下可能涉及較多的鎖競爭和上下文切換。Java 并發(fā)包（java.util.concurrent）提供了如 CountDownLatch, CyclicBarrier, 或 Semaphore 等更高級的同步工具，以及 ExecutorService 結(jié)合 Future 等方式，可以更靈活或高效地實現(xiàn)線程間的協(xié)調(diào)。

67.Kafka 與 RabbitMQ 的消息持久化與可靠性保障機制

確保消息在傳輸和處理過程中不丟失是消息隊列系統(tǒng)（如 Kafka 和 RabbitMQ）的核心能力之一。兩者都提供了一系列機制來保障消息的可靠性。

Apache Kafka 通過多方面設(shè)計確保消息持久性：首先是副本機制（Replication）。每個主題分區(qū)可以配置多個副本，分布在不同的 Broker 上。其中一個副本作為領(lǐng)導(dǎo)者（Leader）處理所有讀寫請求，其他副本作為追隨者（Follower）同步數(shù)據(jù)。若領(lǐng)導(dǎo)者失效，一個同步的追隨者會被選舉為新領(lǐng)導(dǎo)者。通過配置 min.insync.replicas 參數(shù)，可以要求至少有多少個同步副本確認寫入后，消息才被視為“已提交”，顯著提高容錯性。其次是生產(chǎn)者確認機制（Acknowledgements, acks）。生產(chǎn)者發(fā)送消息時可配置 acks 參數(shù)：acks=0（不等待確認，性能高但易丟失），acks=1（默認，等待 Leader 確認，Leader 宕機可能丟失），acks=all 或 -1（等待所有 ISR 確認，最可靠但性能稍低）。此外，Kafka 將消息持久化存儲在磁盤上，并通過事務(wù)（Transactions）支持提供精確一次處理語義（EOS）。對于消費者端，通過精確管理消費偏移量（Offset），確保消費者在故障恢復(fù)后能從正確的位置繼續(xù)消費，避免消息丟失（需注意提交時機，通常在消息處理成功后提交）。

RabbitMQ 同樣提供了多種保障消息不丟失的策略：核心機制是消息確認。**消費者確認（Consumer Acknowledgements）**要求消費者在成功處理消息后顯式發(fā)送 ack 給 RabbitMQ，之后 RabbitMQ 才將消息標記為刪除。若消費者在處理中失敗且未發(fā)送 ack，消息會重新投遞。**發(fā)布確認（Publisher Confirms）則讓生產(chǎn)者知道消息是否已成功到達 RabbitMQ 服務(wù)器（交換機）。 持久化（Persistence）是另一關(guān)鍵。需要同時將隊列聲明為持久化（durable）并在發(fā)送消息時將其標記為持久化（delivery mode = 2），這樣即使 RabbitMQ 重啟，隊列結(jié)構(gòu)和消息內(nèi)容都能恢復(fù)。 為處理無法路由或處理失敗的消息，RabbitMQ 支持備份交換機（Alternate Exchange）用于接收無法路由的消息，以及死信隊列（Dead Letter Exchange/Queue）**用于接收被拒絕、過期或隊列溢出的消息，防止這些消息直接丟失。

68.Kafka 如何在多消費者環(huán)境下保證分區(qū)內(nèi)消息的消費順序

Apache Kafka 的一個核心設(shè)計原則是保證單個分區(qū)（Partition）內(nèi)的消息是有序的。即使在存在多個消費者的場景下，這一分區(qū)內(nèi)的順序性也能得到保障，主要原因如下：

首先，消息在分區(qū)內(nèi)是按序存儲的。生產(chǎn)者發(fā)送到特定分區(qū)的消息會被嚴格按照發(fā)送順序追加到該分區(qū)日志（Log）的末尾。每條消息在分區(qū)內(nèi)都會獲得一個唯一的、單調(diào)遞增的偏移量（Offset）。

其次，分區(qū)與消費者的分配機制是關(guān)鍵。Kafka 引入了消費者組（Consumer Group）的概念。對于訂閱了同一個主題的消費者組，主題中的每個分區(qū)在同一時刻最多只能被該組內(nèi)的一個消費者實例所消費。Kafka 負責(zé)將分區(qū)均勻地分配給組內(nèi)的消費者。

因此，盡管一個主題可以被多個消費者（可能屬于不同組，或同一組的多個實例）并行消費，但針對特定分區(qū)的消息流，始終是由消費者組內(nèi)唯一指定的那個消費者實例來順序讀取的。該消費者會維護自己在這個分區(qū)上的消費偏移量，從上次提交的位置開始，按偏移量遞增的順序逐條拉取并處理消息，從而完美地再現(xiàn)了消息在分區(qū)內(nèi)的原始順序。

當(dāng)消費者組內(nèi)成員發(fā)生變化（如增減消費者實例）或主題分區(qū)數(shù)量變化時，會觸發(fā)**再平衡（Rebalance）**過程，重新分配分區(qū)給消費者。即使分區(qū)被重新分配給了組內(nèi)的另一個消費者，新的消費者也會從該分區(qū)上次提交的偏移量開始繼續(xù)按順序消費，保證分區(qū)內(nèi)消息處理的順序性不被破壞。消費者組的設(shè)計實現(xiàn)了消費的負載均衡和高可用性，同時通過限制分區(qū)與消費者的綁定關(guān)系，巧妙地維持了分區(qū)內(nèi)的消息順序。

69.Redis 作為高性能緩存的關(guān)鍵特性及其速度優(yōu)勢來源

Redis 之所以被廣泛用作高性能緩存，得益于其獨特的設(shè)計和一系列關(guān)鍵特性。首先，是其核心優(yōu)勢，內(nèi)存的讀寫速度遠超磁盤，使得 Redis 能夠提供微秒級的低延遲訪問，這對于需要快速響應(yīng)的緩存場景至關(guān)重要。其次，Redis 提供了（如 String, Hash, List, Set, Sorted Set），能夠靈活地滿足多樣化和復(fù)雜的緩存需求，而不僅僅是簡單的鍵值對。再者，Redis 內(nèi)建了，允許為鍵設(shè)置生存時間（TTL），到期后