高頻java運(yùn)維常見(jiàn)面試題及答案JVM內(nèi)存溢出的常見(jiàn)場(chǎng)景有哪些？如何定位和解決？?jī)?nèi)存溢出（OOM）常見(jiàn)于堆內(nèi)存、方法區(qū)（元空間）、直接內(nèi)存（DirectMemory）及線程棧溢出。堆內(nèi)存溢出最常見(jiàn)，典型原因是對(duì)象無(wú)法被GC回收但持續(xù)創(chuàng)建，如緩存未設(shè)置過(guò)期策略或集合類對(duì)象未正確釋放。定位時(shí)可通過(guò)JVM參數(shù)-XX:+HeapDumpOnOutOfMemoryError提供堆轉(zhuǎn)儲(chǔ)文件，使用EclipseMAT或JProfiler分析大對(duì)象引用鏈。方法區(qū)溢出多因動(dòng)態(tài)提供類（如CGLIB代理、反射）或加載大量類未卸載，JDK8后元空間使用本地內(nèi)存，可通過(guò)-XX:MaxMetaspaceSize限制大小，結(jié)合jmap-dump:format=b,file=metaspace.bin<pid>提供元空間快照，檢查類加載器是否泄漏。直接內(nèi)存溢出通常由Unsafe.allocateMemory()或NIO的ByteBuffer.allocateDirect()未正確釋放導(dǎo)致，可用-XX:MaxDirectMemorySize限制，結(jié)合NativeMemoryTracking（NMT）工具（-XX:NativeMemoryTracking=detail）定位分配熱點(diǎn)。線程棧溢出（StackOverflowError）常見(jiàn)于遞歸過(guò)深或?？臻g過(guò)?。J(rèn)1MB），可通過(guò)-Xss參數(shù)調(diào)整棧大小，或優(yōu)化遞歸邏輯為迭代。如何通過(guò)JVM參數(shù)優(yōu)化GC性能？G1收集器的核心參數(shù)有哪些？GC優(yōu)化需結(jié)合應(yīng)用場(chǎng)景（吞吐量/延遲優(yōu)先）和內(nèi)存模型（對(duì)象存活周期）。對(duì)于年輕代，若短生命周期對(duì)象多（如Web請(qǐng)求），可增大年輕代比例（-Xmn或-XX:NewRatio），減少M(fèi)inorGC頻率；若對(duì)象存活時(shí)間長(zhǎng)，需調(diào)整老年代大小。CMS收集器關(guān)注低延遲，需注意ConcurrentModeFailure（并發(fā)收集時(shí)老年代空間不足），可通過(guò)-XX:CMSInitiatingOccupancyFraction設(shè)置觸發(fā)CMS的老年代占用閾值（如65%），并開(kāi)啟-XX:+UseCMSInitiatingOccupancyOnly避免動(dòng)態(tài)調(diào)整。G1收集器適用于大內(nèi)存（>8GB）場(chǎng)景，核心參數(shù)包括：-XX:MaxGCPauseMillis設(shè)置目標(biāo)最大停頓時(shí)間（默認(rèn)200ms），G1會(huì)自動(dòng)調(diào)整Region分配；-XX:G1HeapRegionSize指定Region大?。?-32MB，需為2的冪次）；-XX:InitiatingHeapOccupancyPercent（默認(rèn)45%）控制觸發(fā)全局并發(fā)標(biāo)記的堆占用閾值；-XX:G1ReservePercent保留內(nèi)存比例（默認(rèn)10%），防止晉升失??；-XX:G1MixedGCCountTarget設(shè)置每次混合收集的Region數(shù)量（默認(rèn)8次）。實(shí)際調(diào)優(yōu)中需結(jié)合GC日志（-Xlog:gc:file=gc.log:time,level,tags）分析停頓時(shí)間和回收效率，避免過(guò)度調(diào)參導(dǎo)致自動(dòng)優(yōu)化失效。生產(chǎn)環(huán)境中Java進(jìn)程CPU使用率過(guò)高如何定位？步驟如下：1.使用top命令找到CPU占用最高的Java進(jìn)程PID；2.通過(guò)top-Hp<PID>查看該進(jìn)程下所有線程的CPU使用情況，記錄高CPU線程的TID（十六進(jìn)制格式，如線程ID為1234，轉(zhuǎn)換為0x4D2）；3.執(zhí)行jstack<PID>>thread_dump.log，在日志中搜索0x4D2對(duì)應(yīng)的線程棧，分析線程狀態(tài)（RUNNABLE通常表示正在執(zhí)行Java代碼，WAITING/TIMED_WAITING可能是阻塞）；4.若線程狀態(tài)為RUNNABLE但無(wú)明顯耗時(shí)操作，可能是JNI調(diào)用或GC線程導(dǎo)致，需結(jié)合jstat-gcutil<PID>1000查看GC頻率，或使用perf工具（Linux）分析本地方法調(diào)用；5.代碼層面檢查是否有死循環(huán)（如循環(huán)內(nèi)無(wú)終止條件）、鎖競(jìng)爭(zhēng)（synchronized或Lock長(zhǎng)時(shí)間持有）、正則表達(dá)式回溯（如復(fù)雜正則匹配大字符串）、IO阻塞（如網(wǎng)絡(luò)請(qǐng)求未設(shè)置超時(shí)）。例如，曾遇到某訂單系統(tǒng)CPU飆高，通過(guò)jstack發(fā)現(xiàn)大量線程卡在ConcurrentHashMap的put操作，最終定位為哈希沖突導(dǎo)致鏈表過(guò)長(zhǎng)，升級(jí)JDK8（鏈表轉(zhuǎn)紅黑樹(shù)）后問(wèn)題解決。Docker容器中Java應(yīng)用內(nèi)存限制如何正確配置？常見(jiàn)誤區(qū)有哪些？容器內(nèi)存限制需同時(shí)設(shè)置JVM堆內(nèi)存和容器CGroup限制。若僅設(shè)置容器內(nèi)存（如dockerrun-m2G），JVM默認(rèn)會(huì)探測(cè)主機(jī)內(nèi)存（而非容器限制），可能導(dǎo)致OOM-Killer終止容器。正確配置需：1.容器層面通過(guò)-m/--memory和--memory-swap限制總內(nèi)存（建議swap=memory，避免使用交換區(qū)）；2.JVM層面根據(jù)容器可用內(nèi)存調(diào)整堆大小，如容器分配2G，保留512M給元空間、棧、直接內(nèi)存等，堆設(shè)置為-Xmx1400m；3.對(duì)于JDK8u191+或JDK10+，可開(kāi)啟-XX:+UseContainerSupport（默認(rèn)啟用），JVM會(huì)自動(dòng)感知容器內(nèi)存限制，調(diào)整堆最大值（-XX:MaxRAMPercentage，默認(rèn)75%）。常見(jiàn)誤區(qū)：1.堆內(nèi)存設(shè)置接近容器限制，未留足非堆內(nèi)存空間，導(dǎo)致容器因總內(nèi)存不足被kill；2.使用舊版JDK未啟用容器感知，JVM申請(qǐng)內(nèi)存超過(guò)容器限制；3.忽略容器內(nèi)進(jìn)程（如日志收集sidecar）的內(nèi)存占用，需整體規(guī)劃資源。例如，某微服務(wù)容器設(shè)置-m2G但JVM堆為1.8G，實(shí)際運(yùn)行時(shí)GC線程、日志線程占用額外200M，總內(nèi)存超2G觸發(fā)OOM-Killer，調(diào)整堆為1.5G后穩(wěn)定。Kubernetes中Pod頻繁重啟的可能原因及排查方法？常見(jiàn)原因包括：1.容器健康檢查失?。簂ivenessProbe（存活檢查）失敗會(huì)觸發(fā)重啟，readinessProbe（就緒檢查）失敗僅影響服務(wù)發(fā)現(xiàn)；2.資源不足：內(nèi)存/CPU超量使用觸發(fā)OOM-Killer或CPUthrottling；3.應(yīng)用自身異常：如啟動(dòng)失?。‥xitCode非0）、運(yùn)行中拋出未捕獲異常；4.鏡像問(wèn)題：鏡像拉取失?。?quán)限/網(wǎng)絡(luò)問(wèn)題）、鏡像啟動(dòng)命令錯(cuò)誤；5.節(jié)點(diǎn)問(wèn)題：節(jié)點(diǎn)資源不足、網(wǎng)絡(luò)中斷、內(nèi)核問(wèn)題。排查步驟：1.查看Pod事件：kubectldescribepod<pod-name>，關(guān)注Warning級(jí)事件（如FailedLivenessProbe、OOMKilled）；2.檢查容器日志：kubectllogs<pod-name>-c<container-name>（查看當(dāng)前日志）和kubectllogs<pod-name>-c<container-name>--previous（查看上一次重啟前的日志）；3.分析資源使用：kubectltoppod<pod-name>查看CPU/內(nèi)存使用，結(jié)合節(jié)點(diǎn)資源（kubectltopnode）判斷是否超配；4.驗(yàn)證健康檢查配置：檢查liveness/readiness的httpGet/exec/tcpSocket配置是否正確（如端口、路徑、超時(shí)時(shí)間）；5.測(cè)試鏡像啟動(dòng)：本地用dockerrun啟動(dòng)鏡像，觀察是否能正常運(yùn)行。例如，某SpringBoot應(yīng)用Pod反復(fù)重啟，日志顯示“Connectionrefused”，最終發(fā)現(xiàn)livenessProbe配置的/actuator/health路徑需要SpringBootActuator依賴，而鏡像未包含該依賴導(dǎo)致檢查失敗。如何設(shè)計(jì)Java應(yīng)用的日志收集與分析方案？ELK架構(gòu)的性能瓶頸及優(yōu)化點(diǎn)？日志收集需考慮實(shí)時(shí)性、可靠性、存儲(chǔ)成本。推薦方案：應(yīng)用輸出結(jié)構(gòu)化日志（JSON格式），通過(guò)Filebeat（輕量級(jí)日志采集器）收集并傳輸至Kafka（消息隊(duì)列緩沖，應(yīng)對(duì)日志突發(fā)高峰），Logstash從Kafka消費(fèi)日志，進(jìn)行解析、過(guò)濾、豐富（如添加環(huán)境標(biāo)簽），最終存儲(chǔ)到Elasticsearch，通過(guò)Kibana可視化。關(guān)鍵優(yōu)化點(diǎn)：1.日志格式標(biāo)準(zhǔn)化：統(tǒng)一時(shí)間戳（ISO8601）、服務(wù)名、traceID，便于聚合查詢；2.采樣收集：對(duì)高吞吐量場(chǎng)景（如支付交易日志），按比例采樣（如10%）減少存儲(chǔ)壓力；3.異步日志：使用Logback的AsyncAppender或Log4j2的AsyncLogger，避免同步寫(xiě)日志阻塞業(yè)務(wù)線程；4.分區(qū)與索引管理：Elasticsearch按天創(chuàng)建索引（如logs-2024.05.20），設(shè)置合理的分片數(shù)（單分片建議<50GB），啟用ILM（索引生命周期管理）自動(dòng)滾動(dòng)、收縮、刪除舊索引。ELK常見(jiàn)瓶頸：Logstash作為處理中心，單實(shí)例性能有限（通常處理5000-10000條/秒），可通過(guò)多實(shí)例負(fù)載均衡（Kafka分區(qū)對(duì)應(yīng)多個(gè)Logstash實(shí)例）或使用輕量級(jí)處理（如Filebeat的processors模塊完成簡(jiǎn)單過(guò)濾，減少Logstash負(fù)擔(dān)）。另外，Elasticsearch寫(xiě)入性能可通過(guò)調(diào)整refresh_interval（如30s）、bulk批量提交（增大batch.size）、禁用不必要的字段（_source按需存儲(chǔ)，禁用_all字段）提升。Java應(yīng)用的線程池如何合理配置？核心參數(shù)有哪些？線程池配置需結(jié)合任務(wù)類型（CPU密集型/IO密集型）和負(fù)載特性（突發(fā)/穩(wěn)定）。核心參數(shù)包括：corePoolSize（核心線程數(shù)）、maximumPoolSize（最大線程數(shù)）、keepAliveTime（空閑線程存活時(shí)間）、workQueue（工作隊(duì)列）、RejectedExecutionHandler（拒絕策略）。對(duì)于CPU密集型任務(wù)（如數(shù)據(jù)計(jì)算），核心線程數(shù)建議設(shè)為CPU核心數(shù)+1（避免上下文切換）；IO密集型任務(wù)（如數(shù)據(jù)庫(kù)查詢、網(wǎng)絡(luò)調(diào)用）因線程常阻塞，核心線程數(shù)可設(shè)為CPU核心數(shù)2或更高（經(jīng)驗(yàn)公式：CPU核心數(shù)/(1-阻塞系數(shù))，阻塞系數(shù)=阻塞時(shí)間/總時(shí)間）。工作隊(duì)列選擇：無(wú)界隊(duì)列（LinkedBlockingQueue）可能導(dǎo)致內(nèi)存溢出，適合任務(wù)量可控場(chǎng)景；有界隊(duì)列（ArrayBlockingQueue）需結(jié)合最大線程數(shù)，避免拒絕策略頻繁觸發(fā)；同步移交隊(duì)列（SynchronousQueue）無(wú)緩沖，任務(wù)直接提交給線程，適合短時(shí)間高并發(fā)但快速處理的場(chǎng)景。拒絕策略推薦使用CallerRunsPolicy（調(diào)用者線程執(zhí)行，降低提交速度）或自定義策略（如記錄日志并降級(jí)）。例如，某訂單系統(tǒng)的異步通知線程池（IO密集型），CPU為8核，阻塞系數(shù)0.8，核心線程數(shù)=8/(1-0.8)=40，最大線程數(shù)設(shè)為60，隊(duì)列使用ArrayBlockingQueue（容量200），拒絕策略為CallerRunsPolicy，避免通知延遲。生產(chǎn)環(huán)境中如何監(jiān)控Java應(yīng)用的健康狀態(tài)？關(guān)鍵指標(biāo)有哪些？監(jiān)控需覆蓋應(yīng)用層、JVM層、系統(tǒng)層。應(yīng)用層指標(biāo)：QPS（每秒請(qǐng)求數(shù)）、響應(yīng)時(shí)間（P90/P95/P99）、錯(cuò)誤率（5xx狀態(tài)碼比例）、業(yè)務(wù)關(guān)鍵指標(biāo)（如訂單成功率、支付耗時(shí)）；JVM層指標(biāo)：堆內(nèi)存使用率（年輕代/老年代）、GC次數(shù)/時(shí)間（MinorGC/MajorGC）、元空間使用率、線程數(shù)（RUNNABLE/WAITING狀態(tài)）、類加載數(shù)；系統(tǒng)層指標(biāo)：CPU使用率（用戶態(tài)/內(nèi)核態(tài)）、內(nèi)存使用率（可用內(nèi)存/交換區(qū)）、磁盤(pán)IO（讀寫(xiě)速率、inode使用）、網(wǎng)絡(luò)IO（入站/出站流量、連接數(shù)）。工具選擇：Prometheus+Grafana作為核心監(jiān)控平臺(tái)，通過(guò)Micrometer（Java指標(biāo)收集庫(kù)）暴露應(yīng)用指標(biāo)（/actuator/prometheus），JVM指標(biāo)可通過(guò)JMXExporter或直接使用Micrometer的JVM內(nèi)置指標(biāo)，系統(tǒng)指標(biāo)通過(guò)NodeExporter收集。報(bào)警規(guī)則需區(qū)分緊急程度：如JVM老年代使用率>90%（預(yù)警，可能即將FullGC）、QPS暴跌50%（緊急，可能服務(wù)宕機(jī)）、錯(cuò)誤率>5%（緊急，需立即排查）。例如，某API網(wǎng)關(guān)通過(guò)監(jiān)控發(fā)現(xiàn)P99響應(yīng)時(shí)間從200ms飆升至800ms，結(jié)合JVM指標(biāo)發(fā)現(xiàn)老年代GC時(shí)間增加，最終定位為緩存服務(wù)連接池耗盡，大量線程阻塞等待連接。Java應(yīng)用的安全配置有哪些關(guān)鍵項(xiàng)？如何防范常見(jiàn)安全漏洞？關(guān)鍵配置包括：1.禁用危險(xiǎn)協(xié)議：JDK8及以下默認(rèn)啟用SSLv3、TLS1.0，需通過(guò)jre/lib/security/java.security配置jdk.tls.disabledAlgorithms=SSLv3,TLSv1,TLSv1.1（JDK11+默認(rèn)禁用低版本）；2.限制HTTP方法：Web容器（如Tomcat）配置僅允許GET/POST，禁用PUT/DELETE等危險(xiǎn)方法；3.輸入輸出過(guò)濾：使用OWASPESAPI庫(kù)過(guò)濾XSS、SQL注入攻擊，數(shù)據(jù)庫(kù)操作強(qiáng)制使用預(yù)編譯語(yǔ)句；4.依賴庫(kù)安全：定期使用OWASPDependency-Check掃描第三方庫(kù)，升級(jí)存在CVE漏洞的依賴（如Log4j2的JNDI注入漏洞需升級(jí)至2.17.0+）；5.敏感信息保護(hù)：配置文件中的數(shù)據(jù)庫(kù)密碼、API密鑰使用加密存儲(chǔ)（如SpringCloudConfig+Vault），避免明文存儲(chǔ)；6.HTTPS強(qiáng)制啟用：Tomcat配置SSL證書(shū)（推薦Let’sEncrypt免費(fèi)證書(shū)），設(shè)置security-constraint強(qiáng)制HTTPS訪問(wèn)，并添加HSTS頭（Strict-Transport-Security:max-age=31536000）。常見(jiàn)漏洞防范：反序列化漏洞（禁用ObjectInputStream的readObject()，使用JSON/Protobuf等安全格式）、路徑遍歷（限制文件上傳目錄，使用規(guī)范路徑解析）、SSRF（限制內(nèi)網(wǎng)IP訪問(wèn)，校驗(yàn)URL白名單）。例如，某電商系統(tǒng)因使用舊版Fastjson（1.2.47），未關(guān)閉AutoType功能導(dǎo)致反序列化漏洞，通過(guò)升級(jí)至1.2.83并配置ParserConfig.getGlobalInstance().setAutoTypeSupport(false)修復(fù)。ZooKeeper在分布式系統(tǒng)中的常見(jiàn)應(yīng)用場(chǎng)景？如何排查ZooKeeper集群腦裂？ZooKeeper用于服務(wù)注冊(cè)與發(fā)現(xiàn)（如Dubbo）、分布式鎖（通過(guò)臨時(shí)順序節(jié)點(diǎn)）、配置中心（監(jiān)聽(tīng)節(jié)點(diǎn)變更）、集群選舉（ZAB協(xié)議）、統(tǒng)一命名服務(wù)。腦裂（SplitBrain）指集群因網(wǎng)絡(luò)分區(qū)導(dǎo)致部分節(jié)點(diǎn)形成獨(dú)立集群，各自選舉Leader。排查方法：1.檢查集群節(jié)點(diǎn)間網(wǎng)絡(luò)連通性（telnet<node>2181），確認(rèn)是否存在分區(qū)；2.查看ZooKeeper日志（zookeeper.out），觀察是否有“Attemptingtocreateanewepoch”（可能重新選舉）或“Notconnectedtoleader”（節(jié)點(diǎn)與Leader斷開(kāi)）；3.使用zkCli.sh連接各節(jié)點(diǎn)，執(zhí)行stat命令查看模式（leader/follower/observer），若存在多個(gè)Leader則判定為腦裂；4.檢查集群配置（zoo.cfg）的server列表是否一致，確保所有節(jié)點(diǎn)使用相同的myid和server配置；5.確認(rèn)選舉機(jī)制（默認(rèn)FastLeaderElection）的多數(shù)派原則（集群可用節(jié)點(diǎn)數(shù)>總節(jié)點(diǎn)數(shù)/2），如3節(jié)點(diǎn)集群需至少2節(jié)點(diǎn)存活才能選舉Leader，避免腦裂。預(yù)防措施：?jiǎn)⒂肸ab協(xié)議的多數(shù)派投票，限制客戶端僅連接過(guò)半節(jié)點(diǎn)，使用TCP心跳檢測(cè)（通過(guò)initLimit/syncLimit配置）。例如，某分布式鎖服務(wù)因交換機(jī)故障導(dǎo)致ZooKeeper集群分裂為2個(gè)節(jié)點(diǎn)（總3節(jié)點(diǎn)），其中2節(jié)點(diǎn)形成新集群并選舉Leader，客戶端連接不同集群導(dǎo)致鎖沖突，通過(guò)修復(fù)網(wǎng)絡(luò)并重啟節(jié)點(diǎn)恢復(fù)單集群。Redis與Java應(yīng)用集成時(shí)的常見(jiàn)性能問(wèn)題及優(yōu)化方法？常見(jiàn)問(wèn)題：1.大Key問(wèn)題：?jiǎn)蝹€(gè)Key存儲(chǔ)大量數(shù)據(jù)（如Hash類型有10萬(wàn)字段），導(dǎo)致刪除/修改操作耗時(shí)，觸發(fā)慢日志；2.熱Key問(wèn)題：某個(gè)Key被高頻訪問(wèn)（如秒殺商品庫(kù)存），導(dǎo)致單個(gè)節(jié)點(diǎn)CPU過(guò)高；3.連接池配置不當(dāng)：連接數(shù)過(guò)小導(dǎo)致線程阻塞，連接數(shù)過(guò)大浪費(fèi)資源；4.序列化耗時(shí)：Java對(duì)象使用JDK序列化（性能差、體積大），未使用Protostuff/Jackson等高效序列化；5.事務(wù)/管道濫用：頻繁使用單命令而非管道（pipeline），增加RTT（往返時(shí)間）。優(yōu)化方法：1.大Key拆分：將大Hash拆分為多個(gè)小Hash（如按ID分桶），或使用RedisCluster的HashTag強(qiáng)制分布到同一節(jié)點(diǎn)；2.熱Key緩存：使用本地緩存（Caffeine）緩存熱Key值，減少Redis訪問(wèn)；或在Redis層面使用客戶端分片（如Twemproxy）分散熱Key到多個(gè)節(jié)點(diǎn)；3.連接池調(diào)優(yōu)：設(shè)置maxTotal（最大連接數(shù)，建議CPU核心數(shù)20）、maxIdle（最大空閑連接）、minIdle（最小空閑連接），測(cè)試獲取連接耗時(shí)（<1ms）；4.序列化優(yōu)化：使用Kryo（速度快）或Protostuff（兼容性好）替代JDK序列化，減少內(nèi)存占用和傳輸時(shí)間；5.批量操作：將多個(gè)命令打包為pipeline（如100條命令/次），減少網(wǎng)絡(luò)IO；6.慢日志監(jiān)控：通過(guò)CONFIGSETslowlog-log-slower-than10000（記錄超過(guò)10ms的命令），分析慢操作類型（如KEYS、HGETALL大Key）。例如，某商品詳情頁(yè)因頻繁調(diào)用HGETALL獲取大Key（包含10萬(wàn)SKU信息），導(dǎo)致Redis延遲升高，優(yōu)化為將SKU信息按分類拆分為多個(gè)小Key，并啟用本地緩存熱賣分類，QPS提升3倍。Tomcat性能調(diào)優(yōu)的核心參數(shù)有哪些？如何根據(jù)業(yè)務(wù)場(chǎng)景調(diào)整？Tomcat性能與連接器（Connector）、線程池、內(nèi)存配置相關(guān)。核心參數(shù)：1.Connector的protocol（協(xié)議）：NIO2（org.apache.coyote.http11.Http11Nio2Protocol）適合高并發(fā)，APR（需要安裝native庫(kù)）適合IO密集型；2.maxThreads（最大線程數(shù)）：處理請(qǐng)求的最大線程數(shù)，默認(rèn)200，CPU密集型建議設(shè)為CPU核心數(shù)2，IO密集型（如數(shù)據(jù)庫(kù)查詢）可設(shè)為CPU核心數(shù)5-10（需結(jié)合線程等待時(shí)間）；3.acceptCount（等待隊(duì)列長(zhǎng)度）：當(dāng)線程數(shù)滿時(shí)，新請(qǐng)求在隊(duì)列中等待的最大數(shù)量，默認(rèn)100，設(shè)置過(guò)大會(huì)導(dǎo)致請(qǐng)求延遲，過(guò)小會(huì)觸發(fā)Connectionrefused；4.connectionTimeout（連接超時(shí)）：默認(rèn)20000ms（20秒），根據(jù)業(yè)務(wù)響應(yīng)時(shí)間調(diào)整（如電商秒殺設(shè)為5秒）；5.maxConnections（最大連接數(shù)）：NIO模式下同時(shí)打開(kāi)的連接數(shù)，默認(rèn)10000，需結(jié)合操作系統(tǒng)文件句柄限制（ulimit-n）；6.compression（壓縮）：?jiǎn)⒂肏TTP壓縮（compression="on"），設(shè)置compressableMimeType="text/html,text/css,application/json"，減少傳輸體積。調(diào)優(yōu)示例：某高并發(fā)API服務(wù)（IO密集型，CPU8核），設(shè)置maxThreads=400（850），acceptCount=200，connectionTimeout=5000ms，maxConnections=20000（uli