java開發流程中調優技巧有哪些?java開發中調優是需要做好準備工作的，因爲每一個應用的業務目標不相，同事性能瓶頸不會總在同一個點上。所以學會方法，根據實際情況作調整很重要。接下來我們說說對於調優這個事情來說，分爲三個過程：
java開發流程調優技巧一：性能監控
問題沒有發生，你並不知道你需要調優什麼?此時需要一些系統、應用的監控工具來發現問題。
java開發流程調優技巧二：性能分析
問題已經發生，但是你並不知道問題到底出在哪裏。此時就需要使用工具、經驗對系統、應用進行瓶頸分析，以求定位到問題原因。
java開發流程調優技巧三：性能調優
經過上一步的分析定位到了問題所在，需要對問題進行解決，使用代碼、配置等手段進行優化。
Java調優也不外乎這三步。此外，性能分析、調優等是拋開以下因素的：
系統底層環境：硬件、操作系統等
數據結構和算法的使用
外部系統如數據庫、緩存的使用
調優準備：
調優是需要做好準備工作的，畢竟每一個應用的業務目標都不盡相同，性能瓶頸也不會總在同一個點上。在業務應用層面，我們需要：
需要了解系統的總體架構，明確壓力方向。比如系統的哪一個接口、模塊是使用率最高的，面臨高併發的挑戰。
需要構建測試環境來測試應用的性能，使用ab、loadrunner、jmeter都可以。
對關鍵業務數據量進行分析，這裏主要指的是對一些數據的量化分析，如數據庫一天的數據量有多少;緩存的數據量有多大等
瞭解系統的響應速度、吞吐量、TPS、QPS等指標需求，比如秒殺系統對響應速度和QPS的要求是非常高的。
瞭解系統相關軟件的版本、模式和參數等，有時候限於應用依賴服務的版本、模式等，性能也會受到一定的影響。
性能分析：
在系統層面能夠影響應用性能的一般包括三個因素：CPU、內存和IO，可以從這三方面進行程序的性能瓶頸分析。
CPU分析
當程序響應變慢的時候，首先使用top、vmstat、ps等命令查看系統的cpu使用率是否有異常，從而可以判斷出是否是cpu繁忙造成的性能問題。其中，主要通過us(用戶進程所佔的%)這個數據來看異常的進程信息。當us接近100%甚至更高時，可以確定是cpu繁忙造成的響應緩慢。一般說來，cpu繁忙的原因有以下幾個：
線程中有無限空循環、無阻塞、正則匹配或者單純的計算
發生了頻繁的gc
多線程的上下文切換
內存分析：
對Java應用來說，內存主要是由堆外內存和堆內內存組成。
1. 堆外內存堆外內存主要是JNI、Deflater/Inflater、DirectByteBuffer(nio中會用到)使用的。對於這種堆外內存的分析，還是需要先通過vmstat、sar、top、pidstat等查看swap和物理內存的消耗狀況再做判斷的。此外，對於JNI、Deflater這種調用可以通過Google-preftools來追蹤資源使用狀況。
2. 堆內內存此部分內存爲Java應用主要的內存區域。通常與這部分內存性能相關的有：
創建的對象：這個是存儲在堆中的，需要控制好對象的數量和大小，尤其是大的對象很容易進入老年代
全局集合：全局集合通常是生命週期比較長的，因此需要特別注意全局集合的使用
緩存：緩存選用的數據結構不同，會很大程序影響內存的大小和gc
ClassLoader：主要是動態加載類容易造成永久代內存不足
多線程：線程分配會佔用本地內存，過多的線程也會造成內存不足
O分析：
通常與應用性能相關的包括：文件IO和網絡IO。
文件IO可以使用系統工具pidstat、iostat、vmstat來查看io的狀況。這裏可以看一張使用vmstat的結果圖。
這裏主要注意bi和bo這兩個值，分別表示塊設備每秒接收的塊數量和塊設備每秒發送的塊數量，由此可以判定io繁忙狀況。進一步的可以通過使用strace工具定位對文件io的系統調用。通常，造成文件io性能差的原因不外乎：
大量的隨機讀寫
設備慢
文件太大
網絡IO查看網絡io狀況，一般使用的是netstat工具。可以查看所有連接的狀況、數目、端口信息等。例如：當time_wait或者close_wait連接過多時，會影響應用的相應速度。
性能調優
與性能分析相對應，性能調優同樣分爲三部分。
CPU調優：
不要存在一直運行的線程(無限while循環)，可以使用sleep休眠一段時間。這種情況普遍存在於一些pull方式消費數據的場景下，當一次pull沒有拿到數據的時候建議sleep一下，再做下一次pull。
輪詢的時候可以使用wait/notify機制
避免循環、正則表達式匹配、計算過多，包括使用String的format、split、replace方法(可以使用apache的commons-lang裏的StringUtils對應的方法)，使用正則去判斷郵箱格式(有時候會造成死循環)、序列/反序列化等。
結合jvm和代碼，避免產生頻繁的gc，尤其是full GC。
此外，使用多線程的時候，還需要注意以下幾點：
使用線程池，減少線程數以及線程的切換
多線程對於鎖的競爭可以考慮減小鎖的粒度(使用ReetrantLock)、拆分鎖(類似ConcurrentHashMap分bucket上鎖), 或者使用CAS、ThreadLocal、不可變對象等無鎖技術。此外，多線程代碼的編寫最好使用jdk提供的併發包、Executors框架以及ForkJoin等，此外Discuptor和Actor在合適的場景也可以使用。
內存調優：
內存的調優主要就是對jvm的調優。
合理設置各個代的大小。避免新生代設置過小(不夠用，經常minor gc並進入老年代)以及過大(會產生碎片)，同樣也要避免Survivor設置過大和過小。
選擇合適的GC策略。需要根據不同的場景選擇合適的gc策略。這裏需要說的是，cms並非全能的。除非特別需要再設置，畢竟cms的新生代回收策略parnew並非最快的，且cms會產生碎片。此外，G1直到jdk8的出現也並沒有得到廣泛應用，並不建議使用。
jvm啓動參數配置-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:[log_path]，以記錄gc日誌，便於排查問題。
其中，對於第一點，具體的還有一點建議：
年輕代大小選擇：響應時間優先的應用，儘可能設大，直到接近系統的最低響應時間限制(根據實際情況選擇)。在此種情況下，年輕代收集發生gc的頻率是最小的。同時，也能夠減少到達年老代的對象。吞吐量優先的應用，也儘可能的設置大，因爲對響應時間沒有要求，垃圾收集可以並行進行，建議適合8CPU以上的應用使用。
年老代大小選擇：響應時間優先的應用，年老代一般都是使用併發收集器，所以其大小需要小心設置，一般要考慮併發會話率和會話持續時間等一些參數。如果堆設置小了，會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式;如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：
併發垃圾收集信息
持久代併發收集次數
傳統GC信息
花在年輕代和年老代回收上的時間比例
一般吞吐量優先的應用都應該有一個很大的年輕代和一個較小的年老代。這樣可以儘可能回收掉大部分短期對象，減少中期的對象，而年老代存放長期存活對象。
此外，較小堆引起的碎片問題：因爲年老代的併發收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，會把相鄰的空間進行合併，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以後，就會出現“碎片”，如果併發收集器找不到足夠的空間，那麼併發收集器將會停止，然後使用傳統的標記、清除方式進行回收。如果出現“碎片”，可能需要進行如下配置：-XX:+UseCMSCompactAtFullCollection，使用併發收集器時，開啓對年老代的壓縮。同時使用-XX:CMSFullGCsBeforeCompaction=xx設置多少次Full GC後，對年老代進行壓縮。
其餘對於jvm的優化問題可見後面JVM參數進階一節。
關於java開發流程中調優技巧還有很多細節，篇幅有限這裏小編就不一一詳說了，想了解跟多java開發流程中調優技巧知識可以通過小編分享的內容繼續往下拓展延伸,希望能幫到你!