Java性能调优笔记

转自:http://www.voidcn.com/article/p-ojikchdt-qp.html

调优步骤:衡量系统现状、设定调优目标、寻找性能瓶颈、性能调优、衡量是否到达目标(如果未到达目标,需重新寻找性能瓶颈)、性能调优结束。

寻找性能瓶颈
性能瓶颈的表象:资源消耗过多、外部处理系统的性能不足、资源消耗不多但程序的响应速度却仍达不到要求。

资源消耗:CPU、文件IO、网络IO、内存。
外部处理系统的性能不足:所调用的其他系统提供的功能或数据库操作的响应速度不够。
资源消耗不多但程序的响应速度却仍达不到要求:程序代码运行效率不够高、未充分使用资源、程序结构不合理。

CPU消耗分析
CPU主要用于中断、内核、用户进程的任务处理,优先级为中断>内核>用户进程。

上下文切换:
每个线程分配一定的执行时间,当到达执行时间、线程中有IO阻塞或高优先级线程要执行时,将切换执行的线程。在切换时要存储目前线程的执行状态,并恢复要执行的线程的状态。
对于Java应用,典型的是在进行文件IO操作、网络IO操作、锁等待、线程Sleep时,当前线程会进入阻塞或休眠状态,从而触发上下文切换,上下文切换过多会造成内核占据较多的CPU的使用。

运行队列:
每个CPU核都维护一个可运行的线程队列。系统的load主要由CPU的运行队列来决定。
运行队列值越大,就意味着线程会要消耗越长的时间才能执行完成。

利用率:
CPU在用户进程、内核、中断处理、IO等待、空闲,这五个部分使用百分比。

文件IO消耗分析
Linux在操作文件时,将数据放入文件缓存区,直到内存不够或系统要释放内存给用户进程使用。所以通常情况下只有写文件和第一次读取文件时会产生真正的文件IO。
对于Java应用,造成文件IO消耗高主要是多个线程需要进行大量内容写入(例如频繁的日志写入)的动作、磁盘设备本身的处理速度慢、文件系统慢、操作的文件本身已经很大。

网络IO消耗分析
对于分布式Java应用,网卡中断是不是均衡分配到各CPU(cat/proc/interrupts查看)。

内存消耗分析(-Xms和-Xmx设为相同的值,避免运行期JVM堆内存要不断申请内存)
对于Java应用,内存的消耗主要在Java堆内存上,只有创建线程和使用Direct ByteBuffer才会操作JVM堆外的内存。
JVM内存消耗过多会导致GC执行频繁,CPU消耗增加,应用线程的执行速度严重下降,甚至造成OutOfMemoryError,最终导致Java进程退出。

JVM堆外的内存
swap的消耗、物理内存的消耗、JVM内存的消耗。

程序执行慢原因分析

锁竞争激烈:很多线程竞争互斥资源,但资源有限, 造成其他线程都处于等待状态。

未充分使用硬件资源:线程操作被串行化。

数据量增长:单表数据量太大(如1个亿)造成数据库读写速度大幅下降(操作此表)。

调优

JVM调优(最关键参数为:-Xms -Xmx -Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold)

代大小调优:避免新生代大小设置过小、避免新生代大小设置过大、避免Survivor设置过小或过大、合理设置新生代存活周期。

-Xmn 调整新生代大小,新生代越大通常也意味着更多对象会在minor GC阶段被回收,但可能有可能造成旧生代大小,造成频繁触发Full GC,甚至是OutOfMemoryError。

-XX:SurvivorRatio调整Eden区与Survivor区的大小,Eden 区越大通常也意味着minor GC发生频率越低,但可能有可能造成Survivor区太小,导致对象minor GC后就直接进入旧生代,从而更频繁触发Full GC。

GC策略的调优:CMS GC多数动作是和应用并发进行的,确实可以减小GC动作给应用造成的暂停时间。对于Web应用非常需要一个对应用造成暂停时间短的GC,再加上Web应用 的瓶颈都不在CPU上,在G1还不够成熟的情况下,CMS GC是不错的选择。

(如果系统不是CPU密集型,且从新生代进入旧生代的大部分对象是可以回收的,那么采用CMS GC可以更好地在旧生代满之前完成对象的回收,更大程度降低Full GC发生的可能)

在调整了内存管理方面的参数后应通过-XX:PrintGCDetails、-XX:+PrintGCTimeStamps、 -XX:+PrintGCApplicationStoppedTime以及jstat或visualvm等方式观察调整后的GC状况。

出内存管理以外的其他方面的调优参数:-XX:CompileThreshold、-XX:+UseFastAccessorMethods、 -XX:+UseBaiasedLocking。

程序调优

CPU消耗严重的解决方法

CPU us高的解决方法:

CPU us 高的原因主要是执行线程不需要任何挂起动作,且一直执行,导致CPU 没有机会去调度执行其他的线程。

调优方案: 增加Thread.sleep,以释放CPU 的执行权,降低CPU 的消耗。以损失单次执行性能为代价的,但由于其降低了CPU 的消耗,对于多线程的应用而言,反而提高了总体的平均性能。

(在实际的Java应用中类似场景, 对于这种场景最佳方式是改为采用wait/notify机制)

对于其他类似循环次数过多、正则、计算等造成CPU us过高的状况, 则需要结合业务调优。

对于GC频繁,则需要通过JVM调优或程序调优,降低GC的执行次数。

CPU sy高的解决方法:

CPU sy 高的原因主要是线程的运行状态要经常切换,对于这种情况,常见的一种优化方法是减少线程数。

调优方案: 将线程数降低

这种调优过后有可能会造成CPU us过高,所以合理设置线程数非常关键。

对于Java分布式应用,还有一种典型现象是应用中有较多的网络IO操作和确实需要一些锁竞争机制(如数据库连接池),但为了能够支撑搞得并发量,可采用协程(Coroutine)来支撑更高的并发量,避免并发量上涨后造成CPU sy消耗严重、系统load迅速上涨和系统性能下降。

在Java中实现协程的框架有Kilim,Kilim执行一项任务创建Task,使用Task的暂停机制,而不是Thread,Kilim承担了线程调度以及上下切换动作,Task相对于原生Thread而言就轻量级多了,且能更好利用CPU。Kilim带来的是线程使用率的提升,但同时由于要在JVM堆中保存Task上下文信息,因此在采用Kilim的情况下要消耗更多的内存。(目前JDK 7中也有一个支持协程方式的实现,另外基于JVM的Scala的Actor也可用于在Java使用协程)

文件IO消耗严重的解决方法

从程序的角度而言,造成文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件,导致文件很快变得很大,从而写入速度越来越慢,并造成各线程激烈争抢文件锁。

常用调优方法:

异步写文件

批量读写

限流

限制文件大小

网络IO消耗严重的解决方法

从程序的角度而言,造成网络IO消耗严重的原因主要是同时需要发送或接收的包太多。

常用调优方法:

限流,限流通常是限制发送packet的频率,从而在网络IO消耗可接受的情况下来发送packget。

内存消耗严重的解决方法

释放不必要的引用:代码持有了不需要的对象引用,造成这些对象无法被GC,从而占据了JVM堆内存。(使用ThreadLocal:注意在线程内动作执行完毕时,需执行ThreadLocal.set把对象清除,避免持有不必要的对象引用)

使用对象缓存池:创建对象要消耗一定的CPU以及内存,使用对象缓存池一定程度上可降低JVM堆内存的使用。

采用合理的缓存失效算法:如果放入太多对象在缓存池中,反而会造成内存的严重消耗, 同时由于缓存池一直对这些对象持有引用,从而造成Full GC增多,对于这种状况要合理控制缓存池的大小,避免缓存池的对象数量无限上涨。(经典的缓存失效算法来清除缓存池中的对象:FIFO、LRU、LFU等)

合理使用SoftReference和WeekReference:SoftReference的对象会在内存不够用的时候回收,WeekReference的对象会在Full GC的时候回收。

资源消耗不多但程序执行慢的情况的解决方法

降低锁竞争: 多线多了,锁竞争的状况会比较明显,这时候线程很容易处于等待锁的状况,从而导致性能下降以及CPU sy上升。

使用并发包中的类:大多数采用了lock-free、nonblocking算法。

使用Treiber算法:基于CAS以及AtomicReference。

使用Michael-Scott非阻塞队列算法:基于CAS以及AtomicReference,典型ConcurrentLindkedQueue。

(基于CAS和AtomicReference来实现无阻塞是不错的选择,但值得注意的是,lock-free算法需不断的循环比较来保证资源的一致性的,对于冲突较多的应用场景而言,会带来更高的CPU消耗,因此不一定采用CAS实现无阻塞的就一定比采用lock方式的性能好。 还有一些无阻塞算法的改进:MCAS、WSTM等)

尽可能少用锁:尽可能只对需要控制的资源做加锁操作(通常没有必要对整个方法加锁,尽可能让锁最小化,只对互斥及原子操作的地方加锁,加锁时尽可能以保护资源的最小化粒度为单位–如只对需要保护的资源加锁而不是this)。

拆分锁:独占锁拆分为多把锁(读写锁拆分、类似ConcurrentHashMap中默认拆分为16把锁),很多程度上能提高读写的性能,但需要注意在采用拆分锁后,全局性质的操作会变得比较复杂(如ConcurrentHashMap中size操作)。(拆分锁太多也会造成副作用,如CPU消耗明显增加)

去除读写操作的互斥:在修改时加锁,并复制对象进行修改,修改完毕后切换对象的引用,从而读取时则不加锁。这种称为CopyOnWrite,CopyOnWriteArrayList是典型实现,好处是可以明显提升读的性能,适合读多写少的场景, 但由于写操作每次都要复制一份对象,会消耗更多的内存。

充分利用硬件资源(CPU和内存):

充分利用CPU

在能并行处理的场景中未使用足够的线程(线程增加:CPU资源消耗可接受且不会带来激烈竞争锁的场景下), 例如单线程的计算,可以拆分为多个线程分别计算,最后将结果合并,JDK 7中的fork-join框架。

Amdahl定律公式:1/(F+(1-F)/N)。

充分利用内存

数据的缓存、耗时资源的缓存(数据库连接创建、网络连接的创建等)、页面片段的缓存。

毕竟内存的读取肯定远快于硬盘、网络的读取, 在内存消耗可接受、GC频率、以及系统结构(例如集群环境可能会带来缓存的同步)可接受情况下,应充分利用内存来缓存数据,提升系统的性能。

总结:

好的调优策略是收益比(调优后提升的效果/调优改动所需付出的代价)最高的,通常来说简单的系统调优比较好做,因此尽量保持单机上应用的纯粹性, 这是大型系统的基本架构原则。

调优的三大有效原则:充分而不过分使用硬件资源、合理调整JVM、合理使用JDK包。

学习参考资料:

《分布式Java应用:基础与实践》

补充《分布式Java应用:基础与实践》一些代码样例:

cpu———————————–

CpuNotUseEffectiveDemo

[java] view plain copy
/**
*
*/
package tune.program.cpu;
import java.util.ArrayList;
import java.util.List;
import java.util.Random;
/**
* 未充分利用CPU:在能并行处理的场景中未使用足够的线程(线程增加:CPU资源消耗可接受且不会带来激烈竞争锁的场景下)
*
* @author 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));  
    }  

    long 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( " + 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;  

    public 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 {  
                Thread.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
*/

CpuUseEffectiveDemo

[java] view plain copy
/**
*
*/
package tune.program.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 {

private 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 Task[TASK_THREADCOUNT];  
    for (int i = 0; i < TASK_THREADCOUNT; i++) {  
        tasks[i] = new Task();  
    }  
    for (int i = 0; i < taskCount; i++) {  
        int mod = i % TASK_THREADCOUNT;  
        tasks[mod].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_THREADCOUNT);  
        for (int j = 0; j < TASK_THREADCOUNT; j++) {  
            Thread thread = new Thread(tasks[j]);  
            thread.start();  
        }  
        latch.await();  
    }  
    long endTime = System.currentTimeMillis();  
    System.out.println("Execute summary: Round( " + 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;  

    public 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 {  
                Thread.sleep(random.nextInt(10));  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  

            removeTasks.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——————————————————————-

IOWaitHighDemo

[java] view plain copy
/**
*
*/
package tune.program.fileio;
import java.io.BufferedWriter;
import java.io.File;
import java.io.FileWriter;
import java.util.Random;
/**
* 文件IO消耗严重的原因主要是多个线程在写进行大量的数据到同一文件,
* 导致文件很快变得很大,从而写入速度越来越慢,并造成各线程激烈争抢文件锁。
*
* @author yangwm Aug 21, 2010 9:48:34 PM
*/
public class IOWaitHighDemo {
private String fileName = “iowait.log”;

private static int threadCount = Runtime.getRuntime().availableProcessors();  

private Random random = new Random();  

public static void main(String[] args) throws Exception {  
    if (args.length == 1) {  
        threadCount = Integer.parseInt(args[1]);  
    }  

    IOWaitHighDemo demo = new IOWaitHighDemo();  
    demo.runTest();  
}  

private void runTest() throws 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 = 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();  
                Thread.sleep(random.nextInt(10));  
            } catch (Exception e) {  

            }  
        }  
    }  

}

}
/*
C:/Documents and Settings/yangwm>jstack 2656
2010-08-21 23:24:17
Full thread dump Java 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.FileOutputStream.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.close(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)atjava.lang.Thread.run(Thread.java:717)Thread0prio=6tid=0x0ab9d400nid=0x80crunnable[0x0b06f000]java.lang.Thread.State:RUNNABLEatjava.io.FileOutputStream.writeBytes(NativeMethod)atjava.io.FileOutputStream.write(FileOutputStream.java:292)atsun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)atsun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:282)atsun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)locked<0x034e1290>(ajava.io.FileWriter)atjava.io.OutputStreamWriter.write(OutputStreamWriter.java:207)atjava.io.BufferedWriter.flushBuffer(BufferedWriter.java:128)locked<0x034e1290>(ajava.io.FileWriter)atjava.io.BufferedWriter.write(BufferedWriter.java:229)locked<0x034e1290>(ajava.io.FileWriter)atjava.io.Writer.write(Writer.java:157)attune.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 [0x00000000]
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: RUNNABLE
“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(Native Method)
- waiting on <0x02f15d90> (a java.lang.ref.ReferenceQueue Lock)atjava.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)locked<0x02f15d90>(ajava.lang.ref.ReferenceQueue Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer FinalizerThread.run(Finalizer.java:177)ReferenceHandlerdaemonprio=10tid=0x0ab4f800nid=0x8a4inObject.wait()[0x0ac3f000]java.lang.Thread.State:WAITING(onobjectmonitor)atjava.lang.Object.wait(NativeMethod)waitingon<0x02f15af8>(ajava.lang.ref.Reference Lock)
at java.lang.Object.wait(Object.java:502)
at java.lang.ref.Reference ReferenceHandler.run(Reference.java:133)locked<0x02f15af8>(ajava.lang.ref.Reference Lock)
“VM Thread” prio=10 tid=0x0ab4a800 nid=0x1d0 runnable
“VM Periodic Task Thread” prio=10 tid=0x0ab7d400 nid=0x464 waiting on condition
JNI global references: 693

C:/Documents and Settings/yangwm>
*/

LogControl

[java] view plain copy
/**
*
*/
package tune.program.fileio;
import java.util.concurrent.atomic.AtomicInteger;
/**
* 日志控制:采用简单策略为统计一段时间内日志输出频率, 当超出这个频率时,一段时间内不再写log
*
* @author yangwm Aug 24, 2010 10:41:43 AM
*/
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;  

// 由于控制不用非常精确, 因此忽略此处的并发问题  
public static boolean isLog() {  
    //System.out.println(count.get() + ", " + beginTime + ", " + punishTimeEnd + ", " + System.currentTimeMillis());  

    // 不写日志阶段   
    if (punishTimeEnd > 0 && punishTimeEnd > System.currentTimeMillis()) {  
        return false;  
    }  

    // 重新计数  
    if (count.getAndIncrement() == 0) {  
        beginTime = System.currentTimeMillis();  
        return true;  
    } else { // 已在计数  
        // 超过阀门值, 设置count为0并设置一段时间内不写日志  
        if (count.get() > ERROR_THRESHOLD) {  
            count.set(0);  
            punishTimeEnd = PUNISH_TIME + System.currentTimeMillis();  
            return false;  
        }   
        // 没超过阀门值, 且当前时间已超过计数周期,则重新计算   
        else if (System.currentTimeMillis() > (beginTime + INTERVAL)) {  
            count.set(0);  
        }  

        return true;  
    }  
}

}
/*
errorInfo 1
errorInfo 2
……
errorInfo 99
errorInfo 100
errorInfo 601
errorInfo 602
……
errorInfo 699
errorInfo 700
*/

memory——————————————————————-

MemoryHighDemo

[java] view plain copy
/**
*
*/
package tune.program.memory;
import java.nio.ByteBuffer;
/**
* direct bytebuffer消耗的是jvm堆外的内存,但同样是基于GC方式来释放的。
*
* @author yangwm Aug 21, 2010 9:40:18 PM
*/
public class MemoryHighDemo {

public static void main(String[] args) throws Exception{  
    Thread.sleep(20000);  
    System.out.println("read to create bytes,so jvm heap will be used");  
    byte[] bytes=new byte[128*1000*1000];  
    bytes[0]=1;  
    bytes[1]=2;  
    Thread.sleep(10000);  
    System.out.println("read to allocate & put direct bytebuffer,no jvm heap should be used");  
    ByteBuffer buffer=ByteBuffer.allocateDirect(128*1024*1024);  
    buffer.put(bytes);  
    buffer.flip();  
    Thread.sleep(10000);  
    System.out.println("ready to gc,jvm heap will be freed");  
    bytes=null;  
    System.gc();  
    Thread.sleep(10000);  
    System.out.println("read to get bytes,then jvm heap will be used");  
    byte[] resultbytes=new byte[128*1000*1000];  
    buffer.get(resultbytes);  
    System.out.println("resultbytes[1] is: "+resultbytes[1]);  
    Thread.sleep(10000);  
    System.out.println("read to gc all");  
    buffer=null;  
    resultbytes=null;  
    System.gc();  
    Thread.sleep(10000);  
}

}
/*
D:/study/tempProject/JavaLearn/classes>java -Xms140M -Xmx140M tune.MemoryHighDemo
read to create bytes,so jvm heap will be used
read to allocate & put direct bytebuffer,no jvm heap should be used
ready to gc,jvm heap will be freed
read to get bytes,then jvm heap will be used
resultbytes[1] is: 2
read to gc all
*/

ObjectCachePool

[java] view plain copy /** * */ package tune.program.memory; import java.util.LinkedHashMap; import java.util.Map; import java.util.Set; /** * 采用合理的缓存失效算法: FIFO、LRU、LFU等 * * @author yangwm Aug 24, 2010 6:06:48 PM */ public class ObjectCachePool

相关文章