Java性能調(diào)優(yōu)筆記

1、Java性能調(diào)優(yōu)筆記Java性能調(diào)優(yōu)筆記調(diào)優(yōu)步驟：衡量系統(tǒng)現(xiàn)狀、設(shè)定調(diào)優(yōu)目標(biāo)、尋找性能瓶頸、性能調(diào)優(yōu)、衡量是否到達(dá)目標(biāo)(如果未到達(dá)目標(biāo)，需重新尋找性能瓶頸）、性能調(diào)優(yōu)結(jié)束。尋找性能瓶頸性能瓶頸的表象：資源消耗過多、外部處理系統(tǒng)的性能不足、資源消耗不多但程序的響應(yīng)速度卻仍達(dá)不到要求。資源消耗：CPU、文件IO、網(wǎng)絡(luò)IO、內(nèi)存。外部處理系統(tǒng)的性能不足：所調(diào)用的其他系統(tǒng)提供的功能或數(shù)據(jù)庫操作的響應(yīng)速度不夠。資源消耗不多但程序的響應(yīng)速度卻仍達(dá)不到要求：程序代碼運(yùn)行效率不夠高、未充分使用資源、程序結(jié)構(gòu)不合理。CPU消耗分析CPU主要用于中斷、內(nèi)核、用戶進(jìn)程的任務(wù)處理，優(yōu)先級為中斷>內(nèi)核>用戶

2、進(jìn)程。上下文切換：每個線程分配一定的執(zhí)行時間，當(dāng)?shù)竭_(dá)執(zhí)行時間、線程中有IO阻塞或高優(yōu)先級線程要執(zhí)行時，將切換執(zhí)行的線程。在切換時要存儲目前線程的執(zhí)行狀態(tài)，并恢復(fù)要執(zhí)行的線程的狀態(tài)。對于Java應(yīng)用，典型的是在進(jìn)行文件IO操作、網(wǎng)絡(luò)IO操作、鎖等待、線程Sleep時，當(dāng)前線程會進(jìn)入阻塞或休眠狀態(tài)，從而觸發(fā)上下文切換，上下文切換過多會造成內(nèi)核占據(jù)較多的CPU的使用。運(yùn)行隊列：每個CPU核都維護(hù)一個可運(yùn)行的線程隊列。系統(tǒng)的load主要由CPU的運(yùn)行隊列來決定。運(yùn)行隊列值越大，就意味著線程會要消耗越長的時間才能執(zhí)行完成。利用率：CPU在用戶進(jìn)程、內(nèi)核、中斷處理、IO等待、空閑，這五個部分使用百分比。文

3、件IO消耗分析Linux在操作文件時，將數(shù)據(jù)放入文件緩存區(qū)，直到內(nèi)存不夠或系統(tǒng)要釋放內(nèi)存給用戶進(jìn)程使用。所以通常情況下只有寫文件和第一次讀取文件時會產(chǎn)生真正的文件IO。對于Java應(yīng)用，造成文件IO消耗高主要是多個線程需要進(jìn)行大量內(nèi)容寫入（例如頻繁的日志寫入）的動作、磁盤設(shè)備本身的處理速度慢、文件系統(tǒng)慢、操作的文件本身已經(jīng)很大。網(wǎng)絡(luò)IO消耗分析對于分布式Java應(yīng)用，網(wǎng)卡中斷是不是均衡分配到各CPU(cat/proc/interrupts查看)。內(nèi)存消耗分析（-Xms和-Xmx設(shè)為相同的值，避免運(yùn)行期JVM堆內(nèi)存要不斷申請內(nèi)存）對于Java應(yīng)用，內(nèi)存的消耗主要在Java堆內(nèi)存上，只有創(chuàng)建線程和

4、使用Direct ByteBuffer才會操作JVM堆外的內(nèi)存。JVM內(nèi)存消耗過多會導(dǎo)致GC執(zhí)行頻繁，CPU消耗增加，應(yīng)用線程的執(zhí)行速度嚴(yán)重下降，甚至造成OutOfMemoryError，最終導(dǎo)致Java進(jìn)程退出。JVM堆外的內(nèi)存swap的消耗、物理內(nèi)存的消耗、JVM內(nèi)存的消耗。程序執(zhí)行慢原因分析鎖競爭激烈：很多線程競爭互斥資源，但資源有限， 造成其他線程都處于等待狀態(tài)。未充分使用硬件資源：線程操作被串行化。數(shù)據(jù)量增長：單表數(shù)據(jù)量太大（如1個億）造成數(shù)據(jù)庫讀寫速度大幅下降（操作此表）。調(diào)優(yōu)JVM調(diào)優(yōu)（最關(guān)鍵參數(shù)為：-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:Max

5、TenuringThreshold）代大小調(diào)優(yōu)：避免新生代大小設(shè)置過小、避免新生代大小設(shè)置過大、避免Survivor設(shè)置過小或過大、合理設(shè)置新生代存活周期。-Xmn 調(diào)整新生代大小，新生代越大通常也意味著更多對象會在minor GC階段被回收，但可能有可能造成舊生代大小，造成頻繁觸發(fā)Full GC，甚至是OutOfMemoryError。-XX:SurvivorRatio調(diào)整Eden區(qū)與Survivor區(qū)的大小，Eden 區(qū)越大通常也意味著minor GC發(fā)生頻率越低，但可能有可能造成Survivor區(qū)太小，導(dǎo)致對象minor GC后就直接進(jìn)入舊生代，從而更頻繁觸發(fā)Full GC。GC策略的調(diào)

6、優(yōu)：CMS GC多數(shù)動作是和應(yīng)用并發(fā)進(jìn)行的，確實可以減小GC動作給應(yīng)用造成的暫停時間。對于Web應(yīng)用非常需要一個對應(yīng)用造成暫停時間短的GC，再加上Web應(yīng)用 的瓶頸都不在CPU上，在G1還不夠成熟的情況下，CMS GC是不錯的選擇。（如果系統(tǒng)不是CPU密集型，且從新生代進(jìn)入舊生代的大部分對象是可以回收的，那么采用CMS GC可以更好地在舊生代滿之前完成對象的回收，更大程度降低Full GC發(fā)生的可能） 在調(diào)整了內(nèi)存管理方面的參數(shù)后應(yīng)通過-XX:PrintGCDetails、-XX:+PrintGCTimeStamps、 -XX:+PrintGCApplicationStoppedTime以及j

7、stat或visualvm等方式觀察調(diào)整后的GC狀況。出內(nèi)存管理以外的其他方面的調(diào)優(yōu)參數(shù)：-XX:CompileThreshold、-XX:+UseFastAccessorMethods、 -XX:+UseBaiasedLocking。程序調(diào)優(yōu)CPU消耗嚴(yán)重的解決方法CPU us高的解決方法：CPU us 高的原因主要是執(zhí)行線程不需要任何掛起動作，且一直執(zhí)行，導(dǎo)致CPU 沒有機(jī)會去調(diào)度執(zhí)行其他的線程。調(diào)優(yōu)方案： 增加Thread.sleep，以釋放CPU 的執(zhí)行權(quán)，降低CPU 的消耗。以損失單次執(zhí)行性能為代價的，但由于其降低了CPU 的消耗，對于多線程的應(yīng)用而言，反而提高了總體的平均性能。（在

8、實際的Java應(yīng)用中類似場景， 對于這種場景最佳方式是改為采用wait/notify機(jī)制）對于其他類似循環(huán)次數(shù)過多、正則、計算等造成CPU us過高的狀況， 則需要結(jié)合業(yè)務(wù)調(diào)優(yōu)。對于GC頻繁，則需要通過JVM調(diào)優(yōu)或程序調(diào)優(yōu)，降低GC的執(zhí)行次數(shù)。 CPU sy高的解決方法：CPU sy 高的原因主要是線程的運(yùn)行狀態(tài)要經(jīng)常切換，對于這種情況，常見的一種優(yōu)化方法是減少線程數(shù)。調(diào)優(yōu)方案： 將線程數(shù)降低這種調(diào)優(yōu)過后有可能會造成CPU us過高，所以合理設(shè)置線程數(shù)非常關(guān)鍵。對于Java分布式應(yīng)用，還有一種典型現(xiàn)象是應(yīng)用中有較多的網(wǎng)絡(luò)IO操作和確實需要一些鎖競爭機(jī)制（如數(shù)據(jù)庫連接池），但為了能夠支撐搞得并發(fā)

9、量，可采用協(xié)程（Coroutine）來支撐更高的并發(fā)量，避免并發(fā)量上漲后造成CPU sy消耗嚴(yán)重、系統(tǒng)load迅速上漲和系統(tǒng)性能下降。在Java中實現(xiàn)協(xié)程的框架有Kilim，Kilim執(zhí)行一項任務(wù)創(chuàng)建Task，使用Task的暫停機(jī)制，而不是Thread，Kilim承擔(dān)了線程調(diào)度以及上下切換動作，Task相對于原生Thread而言就輕量級多了，且能更好利用CPU。Kilim帶來的是線程使用率的提升，但同時由于要在JVM堆中保存Task上下文信息，因此在采用Kilim的情況下要消耗更多的內(nèi)存。（目前JDK 7中也有一個支持協(xié)程方式的實現(xiàn)，另外基于JVM的Scala的Actor也可用于在Java使用

10、協(xié)程）文件IO消耗嚴(yán)重的解決方法從程序的角度而言，造成文件IO消耗嚴(yán)重的原因主要是多個線程在寫進(jìn)行大量的數(shù)據(jù)到同一文件，導(dǎo)致文件很快變得很大，從而寫入速度越來越慢，并造成各線程激烈爭搶文件鎖。常用調(diào)優(yōu)方法：異步寫文件批量讀寫限流限制文件大小網(wǎng)絡(luò)IO消耗嚴(yán)重的解決方法從程序的角度而言，造成網(wǎng)絡(luò)IO消耗嚴(yán)重的原因主要是同時需要發(fā)送或接收的包太多。常用調(diào)優(yōu)方法：限流，限流通常是限制發(fā)送packet的頻率，從而在網(wǎng)絡(luò)IO消耗可接受的情況下來發(fā)送packget。內(nèi)存消耗嚴(yán)重的解決方法釋放不必要的引用：代碼持有了不需要的對象引用，造成這些對象無法被GC，從而占據(jù)了JVM堆內(nèi)存。（使用ThreadLocal

11、：注意在線程內(nèi)動作執(zhí)行完畢時，需執(zhí)行ThreadLocal.set把對象清除，避免持有不必要的對象引用）使用對象緩存池：創(chuàng)建對象要消耗一定的CPU以及內(nèi)存，使用對象緩存池一定程度上可降低JVM堆內(nèi)存的使用。采用合理的緩存失效算法：如果放入太多對象在緩存池中，反而會造成內(nèi)存的嚴(yán)重消耗， 同時由于緩存池一直對這些對象持有引用，從而造成Full GC增多，對于這種狀況要合理控制緩存池的大小，避免緩存池的對象數(shù)量無限上漲。（經(jīng)典的緩存失效算法來清除緩存池中的對象：FIFO、LRU、LFU等）合理使用SoftReference和WeekReference：SoftReference的對象會在內(nèi)存不夠用的

12、時候回收，WeekReference的對象會在Full GC的時候回收。資源消耗不多但程序執(zhí)行慢的情況的解決方法 降低鎖競爭： 多線多了，鎖競爭的狀況會比較明顯，這時候線程很容易處于等待鎖的狀況，從而導(dǎo)致性能下降以及CPU sy上升。使用并發(fā)包中的類：大多數(shù)采用了lock-free、nonblocking算法。使用Treiber算法：基于CAS以及AtomicReference。使用Michael-Scott非阻塞隊列算法：基于CAS以及AtomicReference，典型ConcurrentLindkedQueue。（基于CAS和AtomicReference來實現(xiàn)無阻塞是不錯的選擇，但值得

13、注意的是，lock-free算法需不斷的循環(huán)比較來保證資源的一致性的，對于沖突較多的應(yīng)用場景而言，會帶來更高的CPU消耗，因此不一定采用CAS實現(xiàn)無阻塞的就一定比采用lock方式的性能好。 還有一些無阻塞算法的改進(jìn)：MCAS、WSTM等）盡可能少用鎖：盡可能只對需要控制的資源做加鎖操作（通常沒有必要對整個方法加鎖，盡可能讓鎖最小化，只對互斥及原子操作的地方加鎖，加鎖時盡可能以保護(hù)資源的最小化粒度為單位-如只對需要保護(hù)的資源加鎖而不是this）。拆分鎖：獨(dú)占鎖拆分為多把鎖（讀寫鎖拆分、類似ConcurrentHashMap中默認(rèn)拆分為16把鎖），很多程度上能提高讀寫的性能，但需要注意在采用拆分鎖

14、后，全局性質(zhì)的操作會變得比較復(fù)雜（如ConcurrentHashMap中size操作）。（拆分鎖太多也會造成副作用，如CPU消耗明顯增加）去除讀寫操作的互斥：在修改時加鎖，并復(fù)制對象進(jìn)行修改，修改完畢后切換對象的引用，從而讀取時則不加鎖。這種稱為CopyOnWrite，CopyOnWriteArrayList是典型實現(xiàn)，好處是可以明顯提升讀的性能，適合讀多寫少的場景， 但由于寫操作每次都要復(fù)制一份對象，會消耗更多的內(nèi)存。充分利用硬件資源（CPU和內(nèi)存）： 充分利用CPU在能并行處理的場景中未使用足夠的線程（線程增加：CPU資源消耗可接受且不會帶來激烈競爭鎖的場景下）， 例如單線程的計算，可以拆

15、分為多個線程分別計算，最后將結(jié)果合并，JDK 7中的fork-join框架。Amdahl定律公式：1/(F+(1-F)/N)。 充分利用內(nèi)存數(shù)據(jù)的緩存、耗時資源的緩存（數(shù)據(jù)庫連接創(chuàng)建、網(wǎng)絡(luò)連接的創(chuàng)建等）、頁面片段的緩存。畢竟內(nèi)存的讀取肯定遠(yuǎn)快于硬盤、網(wǎng)絡(luò)的讀取， 在內(nèi)存消耗可接受、GC頻率、以及系統(tǒng)結(jié)構(gòu)（例如集群環(huán)境可能會帶來緩存的同步）可接受情況下，應(yīng)充分利用內(nèi)存來緩存數(shù)據(jù)，提升系統(tǒng)的性能?？偨Y(jié)：好的調(diào)優(yōu)策略是收益比（調(diào)優(yōu)后提升的效果/調(diào)優(yōu)改動所需付出的代價）最高的，通常來說簡單的系統(tǒng)調(diào)優(yōu)比較好做，因此盡量保持單機(jī)上應(yīng)用的純粹性， 這是大型系統(tǒng)的基本架構(gòu)原則。調(diào)優(yōu)的三大有效原則：充分而不過分

16、使用硬件資源、合理調(diào)整JVM、合理使用JDK包。 學(xué)習(xí)參考資料：分布式Java應(yīng)用：基礎(chǔ)與實踐 補(bǔ)充分布式Java應(yīng)用：基礎(chǔ)與實踐一些代碼樣例：cpu- CpuNotUseEffectiveDemojava view plain copy/* * */ package gram.cpu; import java.util.ArrayList; import java.util.List; import java.util.Random; /* * 未充分利用CPU：在能并行處理的場景中未使用足夠的線程（線程增加：CPU資源消耗可接受且不會帶來激烈競爭鎖的場景下） * * aut

17、hor yangwm Aug 25, 2010 9:54:50 AM */ public class CpuNotUseEffectiveDemo private static int executeTimes = 10; private static int taskCount = 200; public static void main(String args) throws Exception Task task = new Task(); for (int i = 0; i < taskCount; i+) task.addTask(Integer.toString(i); lo

18、ng beginTime = System.currentTimeMillis(); for (int i = 0; i < executeTimes; i+) System.out.println("Round: " + (i + 1); Thread thread = new Thread(task); thread.start(); thread.join(); long endTime = System.currentTimeMillis(); System.out.println("Execute summary: Round( " +

19、executeTimes + " ) TaskCount Per Round( " + taskCount + " ) Execute Time ( " + (endTime - beginTime) + " ) ms"); static class Task implements Runnable List<String> tasks = new ArrayList<String>(); Random random = new Random(); boolean exitFlag = false; publi

20、c void addTask(String task) List<String> copyTasks = new ArrayList<String>(tasks); copyTasks.add(task); tasks = copyTasks; Override public void run() List<String> runTasks = tasks; List<String> removeTasks = new ArrayList<String>(); for (String task : runTasks) try Thre

21、ad.sleep(random.nextInt(10); catch (Exception e) e.printStackTrace(); removeTasks.add(task); try Thread.sleep(10); catch (Exception e) e.printStackTrace(); /* Round: 1 . Round: 10 Execute summary: Round( 10 ) TaskCount Per Round( 200 ) Execute Time ( 10687 ) ms */ CpuUseEffectiveDemojava view plain

22、copy/* * */ package gram.cpu; import java.util.ArrayList; import java.util.List; import java.util.Random; import java.util.concurrent.CountDownLatch; /* * 充分利用CPU：在能并行處理的場景中使用足夠的線程（線程增加：CPU資源消耗可接受且不會帶來激烈競爭鎖的場景下） * * author yangwm Aug 25, 2010 9:54:50 AM */ public class CpuUseEffectiveDemo pr

23、ivate static int executeTimes = 10; private static int taskCount = 200; private static final int TASK_THREADCOUNT = 16; private static CountDownLatch latch; public static void main(String args) throws Exception Task tasks = new TaskTASK_THREADCOUNT; for (int i = 0; i < TASK_THREADCOUNT; i+) tasks

24、i = new Task(); for (int i = 0; i < taskCount; i+) int mod = i % TASK_THREADCOUNT; tasksmod.addTask(Integer.toString(i); long beginTime = System.currentTimeMillis(); for (int i = 0; i < executeTimes; i+) System.out.println("Round: " + (i + 1); latch = new CountDownLatch(TASK_THREADCO

25、UNT); for (int j = 0; j < TASK_THREADCOUNT; j+) Thread thread = new Thread(tasksj); thread.start(); latch.await(); long endTime = System.currentTimeMillis(); System.out.println("Execute summary: Round( " + executeTimes + " ) TaskCount Per Round( " + taskCount + " ) Execut

26、e Time ( " + (endTime - beginTime) + " ) ms"); static class Task implements Runnable List<String> tasks = new ArrayList<String>(); Random random = new Random(); boolean exitFlag = false; public void addTask(String task) List<String> copyTasks = new ArrayList<Strin

27、g>(tasks); copyTasks.add(task); tasks = copyTasks; Override public void run() List<String> runTasks = tasks; List<String> removeTasks = new ArrayList<String>(); for (String task : runTasks) try Thread.sleep(random.nextInt(10); catch (Exception e) e.printStackTrace(); removeTasks

28、.add(task); try Thread.sleep(10); catch (Exception e) e.printStackTrace(); latch.countDown(); /* Round: 1 . Round: 10 Execute summary: Round( 10 ) TaskCount Per Round( 200 ) Execute Time ( 938 ) ms */ fileio- IOWaitHighDemojava view plain copy/* * */ package gram.fileio; import java.io.Buffe

29、redWriter; import java.io.File; import java.io.FileWriter; import java.util.Random; /* * 文件IO消耗嚴(yán)重的原因主要是多個線程在寫進(jìn)行大量的數(shù)據(jù)到同一文件， * 導(dǎo)致文件很快變得很大，從而寫入速度越來越慢，并造成各線程激烈爭搶文件鎖。 * * author yangwm Aug 21, 2010 9:48:34 PM */ public class IOWaitHighDemo private String fileName = "iowait.log" private static i

30、nt threadCount = Runtime.getRuntime().availableProcessors(); private Random random = new Random(); public static void main(String args) throws Exception if (args.length = 1) threadCount = Integer.parseInt(args1); IOWaitHighDemo demo = new IOWaitHighDemo(); demo.runTest(); private void runTest() thro

31、ws Exception File file = new File(fileName); file.createNewFile(); for (int i = 0; i < threadCount; i+) new Thread(new Task().start(); class Task implements Runnable Override public void run() while (true) try StringBuilder strBuilder = new StringBuilder("=begin=/n"); String threadName

32、= Thread.currentThread().getName(); for (int i = 0; i < 100000; i+) strBuilder.append(threadName); strBuilder.append("/n"); strBuilder.append("=end=/n"); BufferedWriter writer = new BufferedWriter(new FileWriter(fileName, true); writer.write(strBuilder.toString(); writer.close

33、(); Thread.sleep(random.nextInt(10); catch (Exception e) /* C:/Documents and Settings/yangwm>jstack 2656 2010-08-21 23:24:17 Full thread dump <a href=" class='replace_word' title="Java 知識庫" target='_blank' style='color:#df3434; font-weight:bold;'>Java

34、</a>HotSpot(TM) Client VM (17.0-b05 mixed mode): "DestroyJavaVM" prio=6 tid=0x00868c00 nid=0xde0 waiting on condition 0x00000000 java.lang.Thread.State: RUNNABLE "Thread-1" prio=6 tid=0x0ab9dc00 nid=0xb7c runnable 0x0b0bf000 java.lang.Thread.State: RUNNABLE at java.io.FileO

35、utputStream.close0(Native Method) at java.io.FileOutputStream.close(FileOutputStream.java:336) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:320) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149) - locked <0x034dd268> (a java.io.FileWriter) at java.io.OutputStreamWriter.clos

36、e(OutputStreamWriter.java:233) at java.io.BufferedWriter.close(BufferedWriter.java:265) - locked <0x034dd268> (a java.io.FileWriter) at tune.IOWaitHighDemo$Task.run(IOWaitHighDemo.java:58) at java.lang.Thread.run(Thread.java:717) "Thread-0" prio=6 tid=0x0ab9d400 nid=0x80c runnable 0x

37、0b06f000 java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:292) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282) at sun.nio.cs.Stre

38、amEncoder.write(StreamEncoder.java:125) - locked <0x034e1290> (a java.io.FileWriter) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:207) at java.io.BufferedWriter.flushBuffer(BufferedWriter.java:128) - locked <0x034e1290> (a java.io.FileWriter) at java.io.BufferedWriter.writ

39、e(BufferedWriter.java:229) - locked <0x034e1290> (a java.io.FileWriter) at java.io.Writer.write(Writer.java:157) at tune.IOWaitHighDemo$Task.run(IOWaitHighDemo.java:57) at java.lang.Thread.run(Thread.java:717) "Low Memory Detector" daemon prio=6 tid=0x0ab6f800 nid=0xfb0 runnable 0x00

40、000000 java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x0ab6c800 nid=0x5fc waiting on condition 0x00000000 java.lang.Thread.State: RUNNABLE "Attach Listener" daemon prio=10 tid=0x0ab67800 nid=0x6fc waiting on condition 0x00000000 java.lang.Thread.State: RUN

41、NABLE "Signal Dispatcher" daemon prio=10 tid=0x0ab66800 nid=0x5a0 runnable 0x00000000 java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x0ab54000 nid=0xe74 in Object.wait() 0x0ac8f000 java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Nativ

42、e Method) - waiting on <0x02f15d90> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135) - locked <0x02f15d90> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151) at java.lang.ref.Finalizer

43、$FinalizerThread.run(Finalizer.java:177) "Reference Handler" daemon prio=10 tid=0x0ab4f800 nid=0x8a4 in Object.wait() 0x0ac3f000 java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x02f15af8> (a java.lang.ref.Reference$Lock) at j

44、ava.lang.Object.wait(Object.java:502) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133) - locked <0x02f15af8> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x0ab4a800 nid=0x1d0 runnable "VM Periodic Task Thread" prio=10 tid=0x0ab7d400 nid=0x464

45、waiting on condition JNI global references: 693 C:/Documents and Settings/yangwm> */ LogControljava view plain copy/* * */ package gram.fileio; import java.util.concurrent.atomic.AtomicInteger; /* * 日志控制：采用簡單策略為統(tǒng)計一段時間內(nèi)日志輸出頻率， 當(dāng)超出這個頻率時，一段時間內(nèi)不再寫log * * author yangwm Aug 24, 2010 10:41:43 AM

46、 */ public class LogControl public static void main(String args) for (int i = 1; i <= 1000; i+) if (LogControl.isLog() /logger.error(errorInfo, throwable); System.out.println("errorInfo " + i); / if (i % 100 = 0) try Thread.sleep(1000); catch (InterruptedException e) e.printStackTrace(); private static final long INTERVAL = 1000; private static final long PUNISH_TIME = 5000; private static final int ERROR_THRESHOLD = 100; private static AtomicInteger count = new AtomicInteger(0); private static long beginTime; private static long punishTimeEnd