3、jhat-JavaHeapAnalysisTool用于内存快照文件的分析，当然还有很多类似工具

　　4、jstatd-VirtualMachinejstatDaemon

　　5、jinfo-ConfigurationInfo

　　6、jvisualvm-JavaVirtualMachineMonitoring，Troubleshooting，andProfilingTool

　　7、jconsole-JavaMonitoringandManagementConsole

　　8、jmap-MemoryMapjvm内存分析工具，得到最普遍的使用。

　　jmap-histo<pid>b。log输出内存类占用，对比各时段的内存类，可方便知道回收情况和占用情况。

　　jmap-dump：format=b，file=heap。dump<pid>输出内存快照，可用许多开源工具分析内存快照。

　　jprofile太耗内存，如果静态分析能得出结论的可避免使用

　　9、jstack-StackTrace打印线程的堆栈跟踪信息

　　10、btrace-sun提供的检测工具，很好很强大，用于检测函数耗时等，微浸入。

　　而服务器端的资源监控多用Linux的shell命令如：top，free，vmstat，iostat，uptime等，详细用法不累述。

　　本次测试过程中遇到的几个误区和犯的错误：

　　1、jmeter关于线程组的线程数和ramp-up值的设置，如果设置ramp-up为1秒，线程数为10，我错误的理解为这就是一秒内的请求量。其实是jmeter一秒内启动了10个线程，这10个线程分别发送请求，知道服务器端返回后，再次发送。

　　这个错误的理解直接导致我们的一个异步接口（接口把数据保存在一个无上限queue中，另外起线程来消费）在压力测试过程中，被压垮，以为是内存泄露问题，其实只是我们的服务器没能力处理这样一个数据量。

　　2、在一个日志处理模块中的生产和消费者模型中，产生的线程过多。后经过配置修改了消费者和生产者的比例。但是在定位问题时，产生很多困难，因为不知道是什么线程出现这么多。程序中所有的线程必须命名才方便工具的观察，需要开发中规范和定义好。

　　3、对于任务类型的性能测试没有返回值，我们怎么观察任务处理一条记录的时间，或单位时间内处理记录的条数呢？开发人员习惯在源代码中去修改，并做trace，更好的方法是采用btrace工具来跟踪方法的进出。它在监控方法的耗时，查看某些方法的参数值，监控内存使用情况等一系列场合中使用。

　　4、开发错误的理解org。springframework。scheduling。concurrent。ThreadPoolTaskExecutor类的corePoolSize和maxPoolSize和queueCapacity三者的关系。原以为corePoolSize是启动时变初始化的核心线程数，如果还有任务需要执行，那么就会新建线程到线程池中，直到达到最大maxPoolSize的大小。然后放不下的任务才浸入queueCapacity中存储。而实际情况确是：任务到达corePoolSize之后，就放入queueCapacity的queue中了。造成我们的配置错误，引起串行的任务执行。

　　的确在开发功能测试中没有发现的问题，通过性能测试暴露了出来。除了这些bug之外，我们还确认了我们接口的性能，任务的性能和稳定性。