xu1314的专栏

使用JCONSOLE远程监控JVM_服务器详细配置1、确保WLS使用Sun JDK，java-version2、修改WLS配置文件windows修改E:\bea\user_projects\domains\base_domainJMX\bin\setDomainEnv.cmd添加set MEM_ARGS=-Xms512m -Xmx768m -Dcom.sun.management.

很多开发者都在其系统中见过“java.lang.OutOfMemoryError:PermGenspace”这一问题。这往往是由类加载器相关的内存泄漏以及新类加载器的创建导致的，通常出现于代码热部署时。相对于正式产品，该问题在开发机上出现的频率更高，在产品中最常见的“问题”是默认值太低了。常用的解决方法是将其设置为256MB或更高。 持久代 PermGenspace

使用jstack分析java程序cpu占用率过高的有关问题 使用jstack分析java程序cpu占用率过高的问题 1，使用jps查找出java进程的pid，如3707 2，使用top -p 14292 -H观察该进程中所有线程的CPU占用。 1. [root@cp01-game-dudai-0100.cp01.baidu.com ~]# top -p 14292 -H 2

Socket 编程时，单机最多可以建立多少个 TCP 连接，受到操作系统的影响。Windows 下单机的TCP连接数受多个参数影响：最大TCP连接数[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters] TcpNumConnections = 0x00fffffe (Default = 1

无意中发现一个蛮好的监控jboss的工具，原本是用来监控tomcat的，但也能监控jboss。    监控Tomcat无需特别的配置，基本上拷到WebApps目录即可使用。    这个能执行长期监控，最近正在想找个东西监控Jboss Session，probe还能查看到session的详细内容。    jboss有专门的版本： 下载最新版本，部署成功后：直接摘取官方配置如下

大家在开发J2EE应用时可能经常碰到OOM的问题。出现这种问题的原因就是内存消耗殆尽，创建新的对象时没有可分配的内存了。为了找到真正导致OOM的原因，这里将使用IBM heapAnalyzer工具进行定位。首先要知道，IBM heapAnalyzer是通过分析OOM后的Java heap dump文件的，通过对dump文件的分析找到内存可能泄露的点。了解这个之后，我们首先需要生成dump文件，

1、  服务端安装JProfiler（与客户端版本一致）2、  客户端配置连接：A）、session——integration wizards——New remote integrationB）、选择远程监控的平台windows，点击nextC）、选择jdk版本，如果服务器是64位的jdk则勾上64 bit jvm，点击nextD）、选择等待连接，点击n

一句话 分析 heap profile 文件1 运行应用程序（使用jre版本为1.6以上）2 命令行执行            jmap -dump:format=b,file=d:/heap.hprof    其中d:/heap.hprof   是dump出来的内存映像发文件，可以取任何后缀的名字。 3 使用eclipse 的MAT分析d:/heap.hprof 文件，可

不止一次，我们都萌发过想对运行中程序的底层状况一探究竟的念头。产生这种需求的原因可能是运行缓慢的服务、Java虚拟机(JVM)崩溃、挂起、死锁、频繁的JVM暂停、突然或持续的高CPU使用率、甚至于可怕的内存溢出(OOME)。好消息是现在已有许多工具能帮你得到Java虚拟机运行过程中的不同参数，这些信息有助于你了解其内部状况，从而诊断上述的各种情况。　　在这篇文章中，我将介绍一些优秀的开源工具。

显示java进程内存使用的相关信息jmap pid #打印内存使用的摘要信息 jmap –heap pid #java heap信息 jmap -histo:live pid #统计对象count ，live表示在使用 jmap -histo pid >mem.txt #打印比较简单的各个有多少个对象占了多少内存的信息，一般重定向的文件jmap -dump:format=b,file=

Java本身提供了多种丰富的方法和工具来帮助开发人员查看和分析GC及JVM内存的状况，同时开源界和商业界也有一些工具可用于查看、分析GC及JVM内存的状况。通过这些分析，可以排查程序中内存泄露的问题及调优程序的性能。下面介绍几种常用的免费工具，其中知名的有JProfiler 等。　　1. 输出GC日志　　输出GC日志对于跟踪分析GC的状况来说，无疑是最直接地分析内存回收状况的方法，只是

Top命令监控某个进程的资源占有情况 下面是各种内存：VIRT：virtual memory usage     1、进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据等     2、假如进程申请100m的内存，但实际只使用了10m，那么它会增长100m，而不是实际的使用量 RES：resident memory usage 常驻内存     1、进程当前

其实早就想对于性能问题的定位做一个总结。正好，最近做了一些Java的WEB应用性能问题的定位的专题工作，这里简单记录一些典型的性能问题定位方法。（比如TPS偏低、吞吐量不足等：这些指标问题由下面说的多个指标造成，故不在单独讨论的范围之内） 应用CPU占用偏高，可能的因素包括：逻辑复杂、算法效率低下过度逻辑检查方法：JProfiler检查热点，等到系统稳定以后

一次weblogic调优的经过项目组反应数据库有问题，检查发现sga还用的默认参数，缓冲区命中率很低。根据系统内存调整后，好像系统正常了。数据库调整就算是结束了一天后，我再登这个数据库的时候，发现一个提示说线程已经超过限制，不允许再登录。然后我去修改了process到250，增加并发连接数。然后重启了数据库。当天没发生什么事情，第二天，发现250又被撑满了，这个时候，我就开始换衣中间件

引子，Qpid 使用场景通信是一个基本的需求，正如人与人之间需要交流一样，比较大型的软件系统也往往需要内部或者外部通信。在系统间通信最基础的通信方式是 socket，但 socket 比较底层。使用起来非常不易。如果需要一些高级特性，需要很多的编程负担。与 socket 的原始对应，企业级的应用软件往往有着各种各样从简单到复杂的通信需求，表现为不同的通信模型。常见的有：点对点：

一、JVM 内存模型根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。1、虚拟机栈：每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出S