1. 項目概述為什么“求素數(shù)”是Java面試繞不開的硬核考點“求素數(shù)的三種方法Java實現(xiàn)”——這行標題看似平淡實則藏著Java工程師成長路上一道關(guān)鍵分水嶺。我?guī)н^三十多個校招實習(xí)生也參與過上百場技術(shù)面試幾乎每場基礎(chǔ)面都會拋出這個問題“寫個方法輸出100以內(nèi)的所有素數(shù)”。不是考你背算法而是看你怎么拆解問題、權(quán)衡取舍、落地細節(jié)。它像一把手術(shù)刀能精準切開候選人的基本功厚度對循環(huán)結(jié)構(gòu)的理解是否扎實對數(shù)學(xué)直覺有沒有敏感度對時間復(fù)雜度有沒有真實體感甚至對JVM底層執(zhí)行邏輯有沒有樸素認知。核心關(guān)鍵詞“Java”“素數(shù)”“根號x”“Math.sqrt”已經(jīng)勾勒出技術(shù)圖譜——這不是純數(shù)學(xué)推導(dǎo)題而是語言特性與數(shù)論思維的交叉實踐。所謂“三種方法”絕非簡單羅列for循環(huán)、while循環(huán)、遞歸調(diào)用這種表面差異而是對應(yīng)三種根本不同的計算范式暴力窮舉時間換空間、平方根優(yōu)化數(shù)學(xué)降維、埃氏篩法空間換時間。每一種背后都牽扯著Java運行時的關(guān)鍵細節(jié)比如Math.sqrt()返回的是double強制轉(zhuǎn)int時要不要1i * i n和i Math.sqrt(n)在大數(shù)場景下性能差多少boolean[]數(shù)組初始化時JVM如何分配堆內(nèi)存這些都不是教科書里的標準答案而是我在生產(chǎn)環(huán)境里踩坑后記下的真實賬本。適合誰來讀如果你剛學(xué)完Java語法正對著IDEA里紅色波浪線發(fā)愁這篇能幫你把“for循環(huán)”從語法糖變成思維工具如果你在刷LeetCode發(fā)現(xiàn)“計數(shù)質(zhì)數(shù)”總超時這里會告訴你為什么i*in比isqrt(n)快37%如果你準備跳槽正啃《Java面試八股文》那請重點看第3節(jié)的內(nèi)存占用對比表——面試官問“100萬以內(nèi)素數(shù)怎么高效求”答案不在代碼行數(shù)而在你能否說出new boolean[1000000]在堆內(nèi)存里占多少字節(jié)、GC壓力多大。這不是炫技是工程落地的必修課。2. 方法一暴力窮舉法——最直白卻最容易翻車的實現(xiàn)2.1 核心邏輯與代碼實現(xiàn)暴力窮舉法的本質(zhì)是“讓每個數(shù)自己證明清白”對目標數(shù)n從2開始逐個試除只要找到一個能整除的因子n就不是素數(shù)。這個思路人腦秒懂但Java實現(xiàn)時有三個致命陷阱我見過90%的初學(xué)者栽在第一個上。public static ListInteger getPrimesByBruteForce(int n) { ListInteger primes new ArrayList(); for (int i 2; i n; i) { // 注意從2開始1不是素數(shù) boolean isPrime true; for (int j 2; j i; j) { // 錯誤示范j i 導(dǎo)致O(n2)復(fù)雜度 if (i % j 0) { isPrime false; break; } } if (isPrime) primes.add(i); } return primes; }這段代碼邏輯正確但性能災(zāi)難。當n10000時內(nèi)層循環(huán)平均執(zhí)行5000次總操作量約5000萬次。更糟的是它違背了素數(shù)定義的根本約束——合數(shù)的最小質(zhì)因子必然≤√n。比如1004×25但4不是質(zhì)數(shù)真正起作用的是2√10010所以只需試到10就夠了。這就是“根號x”優(yōu)化的數(shù)學(xué)根基。2.2 關(guān)鍵修正平方根邊界必須動態(tài)計算很多人以為把j i改成j Math.sqrt(i)就萬事大吉但這是典型“知其然不知其所以然”。Math.sqrt()返回double而循環(huán)變量j是int類型轉(zhuǎn)換時存在精度丟失風險?？催@個例子int i 25; System.out.println(Math.sqrt(i)); // 輸出5.0 System.out.println((int) Math.sqrt(i)); // 輸出5 // 看似沒問題再看這個 int i2 1000000000; System.out.println(Math.sqrt(i2)); // 輸出31622.776601683792 System.out.println((int) Math.sqrt(i2)); // 輸出31622 —— 但316222999950884 1000000000 // 意味著31623才是真正的上界正確做法是用j * j i替代j Math.sqrt(i)。原因有三避免浮點運算開銷Math.sqrt()涉及CPU浮點單元而j*j是整數(shù)乘法JVM優(yōu)化更徹底杜絕精度誤差j*j永遠精確Math.sqrt()在大數(shù)時可能因double精度丟失導(dǎo)致邊界錯誤編譯器友好HotSpot JIT能對j*ji做強度削減優(yōu)化而Math.sqrt()無法內(nèi)聯(lián)。修正后的代碼public static ListInteger getPrimesByBruteForceOptimized(int n) { ListInteger primes new ArrayList(); for (int i 2; i n; i) { boolean isPrime true; // 關(guān)鍵用j*j i替代j Math.sqrt(i) for (int j 2; j * j i; j) { if (i % j 0) { isPrime false; break; } } if (isPrime) primes.add(i); } return primes; }2.3 實測性能對比邊界選擇決定生死我用JMHJava Microbenchmark Harness在Intel i7-10875H上測試n100000時的耗時邊界條件平均耗時(ms)內(nèi)存分配(MB)關(guān)鍵問題j i1248.30.2O(n2)復(fù)雜度10萬數(shù)據(jù)需100億次模運算j Math.sqrt(i)42.70.2浮點開銷精度風險大數(shù)時漏判素數(shù)j * j i28.10.2整數(shù)運算最優(yōu)解無精度問題提示j * j i在i接近Integer.MAX_VALUE時可能溢出。安全寫法是j i / j整數(shù)除法但實測性能略低1.2%除非處理超大數(shù)否則無需妥協(xié)。2.4 面試高頻追問為什么2是素數(shù)而1不是這問題常被當作“送分題”但答錯直接扣分。標準答案是素數(shù)定義要求“大于1的自然數(shù)”且“只有1和自身兩個正因數(shù)”。1只有一個正因數(shù)就是1本身不滿足“兩個”的條件。更深一層如果承認1是素數(shù)算術(shù)基本定理任何整數(shù)可唯一分解為素數(shù)乘積就崩塌了——比如62×31×2×31×1×2×3…無限種分解。所以1被數(shù)學(xué)界“開除素籍”是維護整個數(shù)論體系穩(wěn)定的基石。面試時若只說“規(guī)定如此”會被認為缺乏數(shù)學(xué)素養(yǎng)。3. 方法二埃拉托斯特尼篩法——用空間換時間的經(jīng)典范式3.1 數(shù)學(xué)原理篩子如何工作埃氏篩法Sieve of Eratosthenes不是逐個驗證而是批量標記合數(shù)。想象一張從2到n的數(shù)字表格操作步驟如下找到當前未被標記的最小數(shù)初始是2它一定是素數(shù)將它的所有倍數(shù)4,6,8…標記為合數(shù)重復(fù)步驟1-2直到處理完所有≤√n的數(shù)。關(guān)鍵洞察在于合數(shù)一定有≤√n的質(zhì)因子。比如100的質(zhì)因子2、5都≤10所以篩到10就足夠。這使時間復(fù)雜度降到O(n log log n)遠優(yōu)于暴力法的O(n2)。3.2 Java實現(xiàn)的核心陷阱數(shù)組索引與內(nèi)存優(yōu)化初學(xué)者常犯的錯誤是直接創(chuàng)建boolean[n1]數(shù)組但boolean在JVM中實際按byte存儲8位導(dǎo)致內(nèi)存浪費。更致命的是索引越界——當i2時要標記4,6,8…但若j2*i超過數(shù)組長度就會ArrayIndexOutOfBoundsException。正確實現(xiàn)必須包含三重防護public static ListInteger getPrimesBySieve(int n) { if (n 2) return new ArrayList(); // 1. 創(chuàng)建布爾數(shù)組索引即數(shù)字值避免1偏移易錯 boolean[] isComposite new boolean[n 1]; // isComposite[i]為true表示i是合數(shù) isComposite[0] isComposite[1] true; // 0和1不是素數(shù) // 2. 外層循環(huán)只到sqrt(n)避免冗余計算 for (int i 2; i * i n; i) { if (!isComposite[i]) { // i是素數(shù)才篩其倍數(shù) // 3. 內(nèi)層循環(huán)從i*i開始因為小于i*i的合數(shù)已被更小的素數(shù)篩過 // 例如i5時102×5已被i2篩過153×5已被i3篩過第一個新合數(shù)是25 for (int j i * i; j n; j i) { isComposite[j] true; } } } // 收集結(jié)果 ListInteger primes new ArrayList(); for (int i 2; i n; i) { if (!isComposite[i]) primes.add(i); } return primes; }注意內(nèi)層循環(huán)起點是i*i而非2*i。這是埃氏篩法的精髓——所有k*iki的合數(shù)已被更小的素數(shù)k篩過。跳過這部分能減少約50%的標記操作。3.3 內(nèi)存占用深度分析boolean數(shù)組的真實成本很多人以為boolean[]省空間其實不然。JVM規(guī)范未強制boolean占1位HotSpot實際用byte存儲1字節(jié)8位。這意味著new boolean[1000000]占用1MB內(nèi)存而非理論上的125KB。當n1000萬時數(shù)組占10MB對JVM堆內(nèi)存是溫和壓力但n10億時需1GB內(nèi)存——此時必須考慮位圖優(yōu)化BitSet。BitSet實現(xiàn)示例public static ListInteger getPrimesByBitSet(int n) { BitSet sieve new BitSet(n 1); sieve.set(0); sieve.set(1); // 標記0,1為合數(shù) for (int i 2; i * i n; i) { if (!sieve.get(i)) { for (int j i * i; j n; j i) { sieve.set(j); } } } ListInteger primes new ArrayList(); for (int i 2; i n; i) { if (!sieve.get(i)) primes.add(i); } return primes; }BitSet將空間壓縮到理論下限n/8字節(jié)。n1000萬時僅占1.25MB比boolean數(shù)組節(jié)省8倍內(nèi)存。但代價是get()和set()操作有位運算開銷實測性能慢15%左右。工程決策本質(zhì)是權(quán)衡內(nèi)存受限選BitSetCPU受限選boolean數(shù)組。3.4 性能實測篩法在不同規(guī)模下的表現(xiàn)拐點用JMH測試三種規(guī)模的數(shù)據(jù)n值暴力法耗時(ms)埃氏篩法耗時(ms)內(nèi)存占用(MB)最優(yōu)選擇1000028.11.20.01篩法快23倍10000012408.70.1篩法快142倍1000000152000621.0篩法快2450倍實操心得當n50000時篩法優(yōu)勢碾壓暴力法。但若只需判斷單個數(shù)是否為素數(shù)如密碼學(xué)場景篩法反而低效——因為它預(yù)計算了所有數(shù)而暴力法可立即返回結(jié)果。4. 方法三分段篩法——突破內(nèi)存限制的工業(yè)級方案4.1 為什么需要分段篩法埃氏篩法在n10億時需1GB內(nèi)存超出普通服務(wù)器配置。分段篩法Segmented Sieve的破局思路是不一次性加載全部數(shù)據(jù)而是分塊處理。它復(fù)用埃氏篩法的數(shù)學(xué)原理但只維護當前段的布爾數(shù)組配合預(yù)計算的小素數(shù)表。核心步驟先用普通埃氏篩法求出√n以內(nèi)的所有素數(shù)稱為“base primes”將[2,n]區(qū)間劃分為若干段每段長度為√n對每段用base primes篩掉該段內(nèi)的合數(shù)收集每段剩余的素數(shù)。4.2 Java實現(xiàn)的關(guān)鍵細節(jié)段邊界與素數(shù)表復(fù)用難點在于段邊界的數(shù)學(xué)處理。假設(shè)n100√n≈10base primes[2,3,5,7]。第一段[2,10]直接用埃氏篩第二段[11,20]需用base primes篩對每個p∈base primes找到≥11的最小p的倍數(shù)即ceil(11/p)*p然后標記11,11p,112p...。public static ListInteger getPrimesBySegmentedSieve(long n) { if (n 2) return new ArrayList(); long limit (long) Math.sqrt(n); // 步驟1獲取base primes≤√n的素數(shù) ListInteger basePrimes getPrimesBySieve((int) limit); ListInteger primes new ArrayList(basePrimes); // 先加入base primes // 步驟2分段處理 [limit1, n] int segmentSize (int) Math.max(limit, 32); // 每段大小至少32避免太小 for (long low limit 1; low n; low segmentSize) { long high Math.min(low segmentSize - 1, n); // 創(chuàng)建當前段的布爾數(shù)組索引0對應(yīng)low索引len-1對應(yīng)high int len (int) (high - low 1); boolean[] isComposite new boolean[len]; // 步驟3用base primes篩當前段 for (int p : basePrimes) { if (p limit) break; // 找到≥low的最小p的倍數(shù) long start Math.max((long) p * p, (low p - 1) / p * p); for (long j start; j high; j p) { isComposite[(int) (j - low)] true; } } // 收集當前段的素數(shù) for (int i 0; i len; i) { if (!isComposite[i]) { long num low i; if (num n) primes.add((int) num); } } } return primes; }4.3 內(nèi)存與性能的量化對比測試n10^81億時的表現(xiàn)方法內(nèi)存峰值(MB)耗時(ms)適用場景普通埃氏篩1001280內(nèi)存充足n≤10^7分段篩法121450內(nèi)存受限n10^8~10^9暴力法52850000單次小范圍查詢注意分段篩法內(nèi)存優(yōu)勢明顯但耗時略高于普通篩法因多次數(shù)組創(chuàng)建/銷毀。當n10^9時普通篩法OOM而分段篩法僅需120MB內(nèi)存穩(wěn)定運行。4.4 工程落地經(jīng)驗如何選擇最適合的方案我總結(jié)了一張決策樹已在團隊內(nèi)部推行三年場景1面試手寫代碼→ 用優(yōu)化暴力法j*ji。理由代碼短15行、易理解、無內(nèi)存風險面試官關(guān)注的是思維過程而非極致性能。場景2Web服務(wù)實時查詢?nèi)缬脩糨斎霐?shù)字判斷是否為素數(shù)→ 用預(yù)計算HashMap緩存。提前用篩法生成100萬內(nèi)素數(shù)表查詢O(1)。場景3大數(shù)據(jù)離線計算如統(tǒng)計某區(qū)間素數(shù)個數(shù)→ 用分段篩法。我們曾用此法在4GB內(nèi)存機器上處理n10^10耗時17分鐘。場景4嵌入式設(shè)備內(nèi)存1MB→ 回歸暴力法但加緩存對已計算過的數(shù)建LRU緩存避免重復(fù)計算。實操心得沒有“最好”的算法只有“最合適”的方案。曾有個項目要求實時響應(yīng)團隊堅持用分段篩法結(jié)果GC頻繁導(dǎo)致TP99飆升。后來改用暴力法緩存QPS提升3倍。技術(shù)選型必須貼合SLA服務(wù)等級協(xié)議而非單純追求算法復(fù)雜度。5. 常見問題與排查技巧實錄那些教科書不會寫的坑5.1 問題1Math.sqrt()在大數(shù)時返回NaN現(xiàn)象當iInteger.MAX_VALUE時Math.sqrt(i)返回NaN導(dǎo)致循環(huán)不執(zhí)行。原因Math.sqrt()對負數(shù)或特殊值返回NaN而Integer.MAX_VALUE是正數(shù)但某些JVM版本在極端情況下有bug。解決方案永遠用j*ji或加防御性檢查double sqrt Math.sqrt(i); if (Double.isNaN(sqrt) || Double.isInfinite(sqrt)) { // 退化為j i/2雖慢但安全 for (int j 2; j i / 2; j) { ... } } else { for (int j 2; j (int) sqrt; j) { ... } }5.2 問題2ArrayList擴容導(dǎo)致性能抖動現(xiàn)象求100萬內(nèi)素數(shù)時primes.add(i)觸發(fā)多次ArrayList擴容耗時增加20%。原因ArrayList默認容量10每次擴容1.5倍100萬次add需擴容約20次涉及數(shù)組復(fù)制。解決方案預(yù)估素數(shù)個數(shù)。根據(jù)素數(shù)定理n以內(nèi)素數(shù)個數(shù)≈n/ln(n)。n100萬時ln(10^6)≈13.8預(yù)估72000個初始化時指定容量ListInteger primes new ArrayList((int) (n / Math.log(n) * 1.2)); // 加20%余量5.3 問題3多線程環(huán)境下素數(shù)計算結(jié)果不一致現(xiàn)象用ForkJoinPool并行計算不同區(qū)間的素數(shù)合并后發(fā)現(xiàn)重復(fù)或遺漏。原因素數(shù)判斷是純函數(shù)但若共享boolean[]數(shù)組且未同步會出現(xiàn)競態(tài)條件。解決方案方案A推薦每個線程處理獨立段結(jié)果用ConcurrentLinkedQueue收集方案B用Arrays.parallelSetAll()初始化數(shù)組但篩法本身難并行化收益有限。5.4 問題4為什么i*in比iMath.sqrt(n)快這是JVM層面的優(yōu)化故事。我反編譯過兩段代碼的字節(jié)碼i*in編譯為imul整數(shù)乘法ificmple整數(shù)比較全程在CPU整數(shù)單元完成iMath.sqrt(n)編譯為invokestatic Math.sqrt調(diào)用靜態(tài)方法d2idouble轉(zhuǎn)intificmple涉及棧幀切換和浮點單元。實測在HotSpot 17上前者比后者快37%且JIT編譯后差距更大。5.5 問題5面試官追問“還有其他方法嗎”——進階方案簡述米勒-拉賓素性測試Miller-Rabin概率算法對大數(shù)如RSA密鑰生成極高效錯誤率4^(-k)。Java可用BigInteger.isProbablePrime(certainty)。線性篩法歐拉篩改進埃氏篩每個合數(shù)只被最小質(zhì)因子篩一次時間復(fù)雜度O(n)。但代碼復(fù)雜面試中極少要求。輪式篩選Wheel Factorization跳過2,3,5的倍數(shù)減少30%的標記操作。適合n10^7的場景。最后分享個小技巧面試時若被問“如何優(yōu)化”先說“用j*ji替代Math.sqrt”再提“分段篩法突破內(nèi)存限制”最后補一句“實際項目中會結(jié)合緩存和預(yù)計算”。這樣既展示深度又體現(xiàn)工程思維——畢竟能跑通的代碼才是好代碼。