面试总被问受气？这份速查手册帮你3秒答出底层逻辑
面试被问“受气”原理答不上来？别慌，很多老鸟也在这栽过跟头。今天这份速查手册，专门拆解这个高频考点，保你下次面试不卡壳。
1. 什么是“受气”？定位与核心痛点
在分布式系统或高并发场景下，“受气”通常指资源竞争导致的阻塞等待机制。这里特指线程池、连接池或信号量（Semaphore）场景下的“等待-获取”模型。
很多候选人只背了“同步阻塞”，但面试官挖深一层问“为什么不用锁？”或“如何避免活锁？”，就懵了。
核心痛点：误以为“受气”就是 sleep，分不清忙等待（Busy Wait）与让出CPU的被动等待。
不理解公平性与非公平性的底层差异。
不知道在Go的Goroutine中，这种机制是如何被Channel天然优化的。2. 核心差异：Java vs Go 的“受气”实现对比
不同语言对“受气”（资源竞争等待）的处理哲学完全不同。Java偏向显式控制，Go偏向隐式协作。维度
Java (synchronized / ReentrantLock)
Go (Channel / Mutex)等待方式
偏向阻塞线程，让出CPU
偏向Goroutine挂起，不阻塞OS线程开销
线程切换成本高
Goroutine切换成本极低（栈可增长）公平性
可配置公平/非公平
Channel天然FIFO，Mutex无公平性概念调试难度
堆栈清晰，易定位死锁
协程多，需pprof辅助分析阻塞适用场景
复杂业务逻辑、强一致性要求
高并发IO密集、管道处理数据流关键区别：
Java的“受气”是线程级的，一旦阻塞，整个OS线程暂停；Go的“受气”是协程级的，Goroutine挂起后，M（Machine）线程可以调度其他G运行，资源利用率更高。
3. 代码写法对比：同样的“受气”，不同的写法
Java实现：显式锁与等待
Java中常用 ReentrantLock 配合 Condition 实现更细粒度的“受气”控制。
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.Condition;public class ResourcePool {private final Lock lock = new ReentrantLock();private final Condition condition = lock.newCondition();private int available = 5; // 假设资源池大小为5public void acquire() throws InterruptedException {lock.lock();try {// 核心“受气”逻辑：如果资源不足，就等待while (available == 0) {condition.await(); // 释放锁并进入等待队列（受气开始）}available--; // 获取资源} finally {lock.unlock();}}public void release() {lock.lock();try {available++; // 归还资源condition.signal(); // 唤醒一个等待者（受气结束）} finally {lock.unlock();}}
}逐行解析：condition.await()：这是真正的“受气”时刻。线程进入WAIT状态，释放锁，其他线程可以竞争锁。
while循环：必须用while而不是if，防止虚假唤醒（Spurious Wakeup）。
signal() vs signalAll()：前者唤醒一个，后者唤醒所有。高并发下，signalAll()可能导致“惊群效应”，所有线程醒来竞争同一资源，浪费CPU。Go实现：Channel隐式同步
Go通过Channel实现生产者-消费者模型，天然规避了显式锁的复杂性。
package mainimport (fmtsync
)func worker(id int, jobs -chan int, results chan- int, wg *sync.WaitGroup) {defer wg.Done()for j := range jobs {// 模拟处理耗时// 这里没有显式的“受气”，因为接收jobs时如果通道为空，Goroutine会自动挂起fmt.Printf(Worker %d processing job %d\n, id, j)results - j * 2}
}func main() {const numWorkers = 3jobs := make(chan int, 10)results := make(chan int, numWorkers)var wg sync.WaitGroup// 启动工作者for w := 1; w = numWorkers; w++ {wg.Add(1)go worker(w, jobs, results, wg)}// 发送任务for j := 1; j = 5; j++ {jobs - j}close(jobs)// 等待所有工作者完成go func() {wg.Wait()close(results)}()// 收集结果for r := range results {fmt.Println(Result:, r)}
}逐行解析：jobs - j：如果通道满，发送者会阻塞（受气）；如果通道空，接收者会阻塞（受气）。
无锁设计：Go的Channel内部由runtime管理，开发者无需关心锁的粒度，代码更简洁。
优雅退出：通过 close(jobs) 和 range 实现自然结束，避免Java中需要额外判断标志位。4. 进阶技巧与避坑指南
避坑1：Java中的“自旋”陷阱
在低竞争场景下，Java的 synchronized 会尝试自旋（Spin Lock），即CPU空转等待锁释放。如果竞争激烈，自旋会浪费大量CPU。优化建议：JVM会根据竞争情况自适应调整自旋次数。但在高负载下，建议改用 ReentrantLock 并设置 tryLock(timeout)，避免无限等待。避坑2：Go中的“Goroutine泄漏”
如果Channel没有正确关闭，或者接收端永远不读取，发送端的Goroutine会永远阻塞（受气），导致内存泄漏。优化建议：使用 select + context 超时机制。
select {
case jobs - j:
case -ctx.Done():return
}避坑3：公平性选择
Java的 ReentrantLock 默认是非公平的。非公平性能更好，因为减少了上下文切换，但可能导致某些线程长期饥饿。决策建议：高吞吐场景选非公平；对响应时间敏感、要求公平的场景选公平锁。5. 选型建议：什么时候用哪种？场景
推荐方案
理由高并发Web服务
Go Channel
Goroutine轻量，天然适合IO密集型，代码简洁金融交易/强一致性
Java ReentrantLock
锁语义清晰，JVM调优成熟，易审计多线程CPU密集计算
Java synchronized
简单场景下性能足够，无需复杂锁管道数据处理
Go Channel
生产者-消费者模型天然契合，避免共享内存最后提醒：
“受气”本质是资源稀缺下的等待策略。没有最好的方案，只有最合适的场景。面试时，先问清楚并发量、IO占比、一致性要求，再谈技术选型，这才是老手思维。
这个知识点你面试被问过吗？留言说说
