「java监控小马」java大马小马
本篇文章给大家谈谈java监控小马，以及java大马小马对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
- 1、不容忽视的ClassNotFoundException
- 2、如何监控java cpu使用率
- 3、如何监控Java应用程序的Windows内存使用情况
- 4、Java类应用监控应该监控哪些
- 5、JAVA实现业务数据监控解决方案
- 6、java中 怎么监控服务器端运行情况
不容忽视的ClassNotFoundException
相信很多Java开发人员都对这个常见却不招人待见的java.lang.ClassNotFoundException并不陌生。出现这个异常的原因大家都清楚（classpath路径下缺少class文件或者jar包了，或者是类加载器委派的问题等），不过对于它给JVM带来的性能影响可能就不了解了。这个异常可能会严重影响应用程序的响应时间和可伸缩性。
大型的J2EE企业级应用，可能会同时部署有多个应用，由于同时运行着多个类加载器，就很容易导致这类问题。除非发现有业务确实受到影响或者日志监控比较详细，否则很有可能出现了ClassNotFoundException你也不知道，这导致的结果是：JVM类加载的IO开销和线程间的锁竞争给系统带来的性能问题。
本文及文中的示例程序将会告诉你，应当谨慎对待生产系统中出现的ClassNotFoundException异常，并正确的解决它。
想要正确理解这个性能问题，首先你得明白Java类加载模型的机制。ClassNotFoundException意味着JVM无法找到或者加载某个Java类：
Class.forName()方法
ClassLoader.findSysteClass()方法
ClassLoader.loadClass()方法
尽管在JVM的生命周期内，你的应用程序里面的Java类应该只会加载一次，但有些应用可能会依赖于动态的类加载机制。
不管怎么说，不停地加载失败总是很影响性能的，尤其是JDK中默认的java.lang.ClassLoader进行加载的时候。事实上，1.7以上版本的JDK，为了向下兼容，同一个类不能同时被加载，除非这个类加载器被标记为“支持并发”的。你要时刻牢记，同步操作是在类这一级实现的，由于多个Java线程并发地加载，同一个类不停的加载失败会引发线程间的锁竞争。如果是JDK1.6以前则情况更糟糕，因为同步操作是在类加载器这一层完成的。
由于这个原因，像JBoss WildFly8等JavaEE容器都使用了它们内部的并发类加载器来完成应用程序的类加载。这些类加载器都在更细粒度上进行加锁，这样同一个类加载器的实例可以同时加载多个不同的类。这和JDK1.7的优化不谋而和，它支持的并发的自定义类加载器也是防止类加载器出现死锁的现象。
不过，像java.*的系统级别的类，它们的加载还是会由JDK默认的类加载器来完成。这意味着连续的类加载失败还是可能会引发严重的线程锁竞争。这也正是本文接下来要重现并演示的场景。
为了重现并模拟这个问题，我们按照以下的规范写了一个简单的程序：
一个JAX-RS WEB服务执行Class.forName()来加载一个系统包下不存在的类：
JRE: HotSpot JDK 1.7 64位
Java EE容器：JBoss WildFly8
压测工具：Apache JMeter
Java监控工具：JVisualVM
Java故障分析：JVM Thread Dump
JAX-RS服务同时有20个线程在并发的执行。每一次调用都会触发一个ClassNotFoundException。为了减少IO的影响，日志也完全关闭了，我们只关注类加载的竞争冲突。
现在我们来看下JVisualVM在半分钟到一分钟内的监测结果。可以很明显的看到，很多线程都阻塞住了，在等待获取一个对象锁。
分析JVM的threaddump很容易就能定位出问题：线程锁竞争。从运行栈的跟踪信息可以看到，JBoss把类加载的任务委派给了JDK的类加载器。为什么？这是因为这个不存在的java类被认为是属于系统类路径底下，因此JBoss会把它的加载委派给系统的类加载器。这样因为这个类触发了系统级的同步，其它线程只能等待获取锁才能加载它。
很多线程都在等待获取0x00000000ab84c0c8的锁：
这个线程是罪魁祸首——default task 20
现在我们把要加载类的名字更换到应用程序的包下面并重新运行这段程序。
可以看到，不再有阻塞的线程出现了。为什么？我们来看下JVM的thread dump来更好的理解下为什么会出现这个变化。
由于类名不再认为属于Java系统包下，不会发生类加载委派，也就没有同步操作。
由于JBoss认为JDK1.7是一个”安全“的JDK，它会使用ConcurrentClassLoader.performLoadClassUnchecked()方法，也就不会触发对象监视器锁。
没有同步也就不会产生线程锁竞争，也就不会出现没完没了的ClassNotFoundException异常。
值得注意的是JBoss在防止线程锁竞争方面做出了很大的改进，不过重复的类加载的尝试仍然会在一定程度上影响应用的性能，因为搜索JAR包查找Java类会有一定的IO开销，因此也仍需要采取正确的手段进行处理。
希望你能喜欢这篇文章并且对类加载可能会带来的性能影响也有了更好的了解。JDK1.7和现代的Java EE容器都在类加载方面做了很多的优化，比如死锁和锁竞争方面，但是还是会存在潜在的问题。因此，我强烈建议你能密切的关注你的应用程序的表现，记录日志并确保类加载相关的异常比如java.lang.ClassNotFoundException和java.lang.NoClassDefFoundError都能够正确的处理。
如何监控java cpu使用率
1、确定当前系统安装的jdk是1.6版本以上
2、windows系统中有获取cpu使用率的可执行文件exe，只要在java中获取该文件的执行路径，通过Java调用即可。
3、获取操作系统可执行文件目录procCmd
4、调用java的Runtime.getRuntime().exec执行cmd应用程序
5、利用java中sleep来计算睡眠前后cpu的忙碌时间与空闲时间，因为sleep不会释放系统资源
6、根据忙碌时间占总时间的比例来计算cpu使用率！
如何监控Java应用程序的Windows内存使用情况
应用程序很高兴对所有这些活动一无所知。它只知道自己的虚拟地址空间。但是，如果当前在主存中的页面集（称为 驻留集）少于实际要使用的页面集（称为 工作集），应用程序的性能很快就会显著降低。（不幸的是，本文中您将看到，我们要讨论的工具常常交换使用这两个术语，尽管它们指的是完全不同的事物。）
Task Manager 和 PerfMon
我们首先考察两种最常见的工具：Task Manager 和 PerfMon。这两个工具都随 Windows 一起提供，因此由此起步比较容易。
Task Manager
Task Manager 是一种非常见的 Windows 进程监控程序。您可以通过熟悉的 Ctrl-Alt-Delete 组合键来启动它，或者右击任务栏。Processes 选项卡显示了最详细的信息，如图 2 所示。
图 2. Task Manager 进程选项卡
图 2 中显示的列已经通过选择 View -- Select Columns 作了调整。有些列标题非常含糊，但可以在 Task Manager 帮助中找到各列的定义。和进程内存使用情况关系最密切的计数器包括：
Mem Usage（内存使用）：在线帮助将其称为进程的工作集（尽管很多人称之为驻留集）——当前在主存中的页面集。但是这个数值包含能够和其他进程共享的页面，因此要注意避免重复计算。比方说，如果要计算共享同一个 DLL 的两个进程的总内存占用情况，不能简单地把“内存使用”值相加。
Peak Mem Usage（内存使用高峰值）：进程启动以来 Mem Usage（内存使用）字段的最大值。
Page Faults（页面错误）：进程启动以来要访问的页面不在主存中的总次数。
VM Size（虚拟内存大小）：联机帮助将其称为“分配给进程私有虚拟内存总数。”更确切地说，这是进程所 提交的内存。如果进程保留内存而没有提交，那么该值就与总地址空间的大小有很大的差别。
虽然 Windows 文档将 Mem Usage（内存使用）称为工作集，但在该上下文中，它实际上指的是很多人所说的驻留集（resident set），明白这一点很重要。您可以在 Memory Management Reference 术语表（请参阅 参考资料）中找到这些术语的定义。 工作集 更通常的含义指的是一个逻辑概念，即在某一点上为了避免分页操作，进程需要驻留在内存中的那些页面。
PerfMon
随 Windows 一起提供的另一种 Microsoft 工具是 PerfMon，它监控各种各样的计数器，从打印队列到电话。PerfMon 通常在系统路径中，因此可以在命令行中输入 perfmon 来启动它。这个工具的优点是以图形化的方式显示计数器，很容易看到计数器随时间的变化情况。
请在 PerfMon 窗口上方的工具栏中单击 + 按钮，这样会打开一个对话框让您选择要监控的计数器，如图 3a 所示。计数器按照 性能对象分成不同的类别。与内存使用关系最密切的两个类是 Memory 和 Process。选中计数器然后单击 Explain 按钮，就可以看到计数器的定义。说明出现在主对话框下方弹出的单独的窗口中。
Java类应用监控应该监控哪些
当有问题出现时，许多开发人员可能会比较盲目的用这些工具来试探性定位问题，而大多数情况下，这种试探会无功而返。因为这些分析工具主要是侧重Java单方面的分析，比如该系统调用第三方API，如果第三方API有问题，是无法监控到的。还有像文件、DB资源的访问也是是无法监控到的。
除了JAVA自带的监控工具外，我们尝试了第三方的监控工具透视宝，功能相对全面，且易操作。
在功能方面，透视宝都包括：查看执行最慢的10个元素，包括元素执行次数、持续时长和占用时长百分比；查看HTTP请求参数，包括请求的响应状态、链接页面、具体的请求参数及返回结果；查看代码执行堆栈的详细树状信息，包括每个方法的计算时间、总耗时和被调用的次数，您能直接看到特殊标识的最慢方法；查看涉及SQL语句的总耗时排序，包括SQL执行总耗时、执行次数和具体的查询语句；第三方API调用。
JAVA实现业务数据监控解决方案
用mysql就可以吧，以每五分钟统计一次来看：每年的记录数60/5*24*365=105120条，10年才100w，再在开始时间、结束时间字段建个联合索引，不用担心数据库性能。
java中 怎么监控服务器端运行情况
你可以在JSP页面用这三个方法
request.getRemoteAddr()//获取远程IP
request.getRemoteUser()//获取远程用户
request.getRemoteHost()//获取远程主机
可以写方法,请看java.net包下的类.
java.net.InetAddress
java.net.InetSocketAddress
获取IP,主机和端口.
关于java监控小马和java大马小马的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。