s
JBoss Developer Studio 6.0.0.GA for Mac OS X Lion 10.6.3
Installation path:
/Applications/jbdevstudio
Java VM path:
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Following components will be installed:
JBoss Developer Studio 6.0.0.GA
Disk Space:
Available Disk Space: 150.42 GB
/Users/lindows/Documents/jbossRequired Disk Space: 433.98 MB
Work Space
/Users/lindows/Documents/jboss
jboss-as 目录结构(Directory Structure)
http://www.iteye.com/topic/368548
jboss http://love.baihe.com/Reg.action
jboss4.0.2 sqlserver2000 配置多数据源,密码加密
http://superxgz.iteye.com/blog/192778
http://gaoran2008.iteye.com/blog/181110
linux jboss
新到公司里一切都是新的,呵呵。遇到的问题也是很多的,公司主要是作电子商务这一块。于是我接到的一个任务就是在Linux下来配置开发环境。本人虽然工 作了几年,但是对Linux和Jboss还真的不是很了解。现在配置好了所以把经验写下来与大家共享一下。也欢迎指正。
Linux版本:Linux localhost.localdomain 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
JDK版本:jdk-1_5_0_15-linux-i586-rpm.bin
Jboss版本:jboss-4.2.2.GA
这些文件的下载肯定不是难事,这也不是我要说的重点。
我进入系统的用户是用root,呵呵,最大的权限。
JDK安装开始:
1。在根目录下面创建JDK目录:#mkdir jdk
然后用FTP上传你的jdk-1_5_0_15-linux-i586-rpm.bin这个文件到目录下。
2。进入到JDK目录下:#chmod +x jdk-1_5_0_15-linux-i586.rpm.bin给出权限下来让别的用户也能用到。
3。# ./jdk-1_5_0_02-linux-i586.rpm.bin 可以得到一个jdk-1_5_0_15-linux-i586.rpm的文件。
4。# chmod +x jdk-1_5_0_02-linux-i586.rpm 对得到文件进行修改权限。
5。#rpm -ivh jdk-1_5_0_02-linux-i586.rpm 进行安装程序。
此时我们应该看到的是安装的协议,我们就一直按回车键来完成安装。
接下来我们就要设置环境变量了。
6。# vi /etc/profile.d/java.sh 这样作的目的是让所有的用户用到。在编辑java.sh文件的时候,我们进入的是命令模式,所以要进行模式切换,切换到文本模式用i就可以了,然后我们进行编辑,也就是把下面的配置写上去,如下:
JAVA_HOME=/usr/java/jdk1.5.0_15
CLASSPATH=.:$JAVA_HOME/lib.tools.jar
PATH=$JAVA_HOME/bin:$PATH
export JAVA_HOME CLASSPATH PATH
写好了以后,我们要重文本模式转换到命令模式,用esc来切换。然后用:wq保存退出。我们现在是要用来重启机器用
#shutdown -r now 命令就可以做到。好了以后用java -version,得到:
java version "1.5.0_15"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04)
Java HotSpot(TM) Server VM (build 1.5.0_15-b04, mixed mode)
那么恭喜你,JDK安装成功了。
JDK安装成功了,那么就继续安装JBOSS了
8。从本地上文件到系统下,我们要先建立install,thirdparty目录。
#mkdir install
#mkdir thirdparty
然后就上传文件到/usr/local/install/thirdparty/jboss-4.2.2.GA.zip下面。
9。要对文件进行解压缩
#unzip jboss-4.2.2.GA.zip 当然你也可以解压缩到你指定的目录下面去了。
10。要设置环境变量了
#vi /etc/profile
然后在文件加入下面信息:
JBOSS_HOME=/usr/local/install/thirdparty/jboss-4.2.2.GA
PATH=$PATH:/usr/local/install/thirdparty/arm/2.95.3/bin
export JBOSS_HOME PATH
11。我们修改了文件,那么需要让他立即有效
# source /etc/profile
12。#echo $JBOSS_HOME 用来查看你的环境变量是不是输出了。
13。#cd $JBOSS_HOME/bin 进入到bin目录下用:
./run.sh来启动Jboss.
用IP来访问页面,http://127.0.0.1:8080 就可以出现测试页面了。
安装也就基本完成了。
不过我在中间遇到了一个问题,也就是
1。用IP访问不了页面,但启动服务器的话是完全对的,这个问题让我大伤脑经。最后查下来原来是JBOSS启动下需要绑定IP。
解决:
#cd $JBOSS_HOME/bin 目录下去
#vi start.sh 编辑该文件,然后加入 nohup ./run.sh -Djboss.bind.address=服务的IP &
chmod a+x start.sh --赋予权限
./statr.sh
保存退出。运行JBOSS,好了,解决问题。
http://www.jboss.org/download/
http://www.jboss.org/jbossas/downloads/
https://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=610469
http://downloads.sourceforge.net/jboss/jboss-5.0.0.CR1.zip?modtime=1214868617&big_mirror=1
JBoss Tools 2.0.0.CR1下载地址 :
http://sourceforge.net/project/downloading.php?groupname=jboss&filename=JBossTools-2.0.0.CR1-ALL-win32.zip&use_mirror=nchc
Linux版本:http://downloads.sourceforge.net/jboss/JBossTools-2.0.0.CR1-ALL-linux-gtk.zip
Windows版本:http://downloads.sourceforge.net/jboss/JBossTools-2.0.0.CR1-ALL-win32.zip
Mac版本:http://downloads.sourceforge.net/jboss/JBossTools-2.0.0.CR1-ALL-macosx-carbon.zip
Jboss4.03 web-console jmx-console 登录安全设置
http://blog.chinaunix.net/u/11765/showart_224521.html
http://blog.chinaunix.net/u/20644/showart.php?id=334609
jboss4默认用户名和密码
文件:D:\jboss4\server\default\conf\props\jmx-console-users.properties
内容:
# A sample users.properties file for use with the UsersRolesLoginModule
admin=password
文件:D:\jboss4\server\default\conf\props\jmx-console-roles.properties
内容:
# A sample roles.properties file for use with the UsersRolesLoginModule
admin=JBossAdmin,HttpInvoker
http://localhost:8080/
http://localhost:8080/test
http://localhost:8080/jmx-console id:admin pwd:password
http://localhost:8080/invoker
http://localhost:8080/ws4ee
http://localhost:8080/web-console
http://localhost:8080/jbossmq-httpil
http://localhost:8080/ 默认使用8080端口
默认配置了以下服务:
- JMX Console
- JBoss Web Console
为了安全起见,需要用户通过授权进行访问。
首先对JMX-Console进行设置,在《Getting Started with JBoss 4.0 Release 4》 的2.2.3. Security Service小节中给出了方法,但是缺少了一点点东西:
STEP 1:
找到%JBOSS_HOME%/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml文件,根据说明,去掉注释。<jboss-web>
<!-- Uncomment the security-domain to enable security. You will
need to edit the htmladaptor login configuration to setup the
login modules used to authentication users. -->
<security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>STEP 2:
与jboss-web.xml同级目录下还有一个文件web.xml,找到其中的<security-constraint/>节点,根据说明,取消注释。……
<!-- A security constraint that restricts access to the HTML JMX console
to users with the role JBossAdmin. Edit the roles to what you want and
uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
secured access to the HTML JMX console.
-->
<security-constraint>
<web-resource-collection>
<web-resource-name>HtmlAdaptor</web-resource-name>
<description>An example security config that only allows users with the
role JBossAdmin to access the HTML JMX console web application
</description>
<url-pattern>/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>JBossAdmin</role-name>
</auth-constraint>
</security-constraint><security-constraint>
<web-resource-collection>
<web-resource-name>Public</web-resource-name>
<url-pattern>/public/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
</security-constraint>……
STEP 3:
在第一步中的jmx-console安全域和第二步中的运行角色JBossAdmin都是在login-config.xml中配置,我们 在%JBOSS_HOME%/server/default/conf/props下找到它。查找名字为:jmx-console的 application-policy:<application-policy name = "jmx-console">
<authentication>
<login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required">
<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
</login-module>
</authentication>
</application-policy> -
-
文件props/jmx-console-users.properties定义了用户名、密码;props/jmx-console-roles.properties定义了用户所属角色,找到后自行修改或重新定义用户名、密码。 -
配置web-console ,具体方法同jmx-console,就是位置不同:
- jboss-web.xml、web.xml在%JBOSS_HOME%/server/default/deploy/management/console-mgr.sar\web-console.war/WEB-INF下;
- login-config.xml还是原来的那个,把application-policy名为$webConsoleDomain的部分改成你需要的web-console;
- web-console-users.properties、web-console-roles.properties定义了访问web- console的用户、用户角色,具体位置自己去找,使用find /jboss -name web-console-users.properties 找到以后可以修改用户名、密码。
other appServer
http://blog.csdn.net/iihero/archive/2006/08/24/1114477.aspx
jboss4.2.2GA中文文档,包括EJB3.0开发和使用和jms
http://www.itpub.net/thread-986360-1-1.html
jboss exception
http://www.rich-hosp.cn:8080/portal/custLogin.do;jsessionid=C9137DF036A51EA46C12FEA4E9CDEE01
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.NullPointerException org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:408) org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350) javax.servlet.http.HttpServlet.service(HttpServlet.java:690) javax.servlet.http.HttpServlet.service(HttpServlet.java:803) com.neweasy.framework.web.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:30) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
java.lang.NullPointerException com.neweasy.selfhelp.login.CustLoginAction.handleRequest(CustLoginAction.java:53) org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:45) org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:820) org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:755) org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:396) org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350) javax.servlet.http.HttpServlet.service(HttpServlet.java:690) javax.servlet.http.HttpServlet.service(HttpServlet.java:803) com.neweasy.framework.web.filter.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:30) org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
note The full stack trace of the root cause is available in the JBossWeb/2.0.1.GA logs.
JBossWeb/2.0.1.GA
http://www.mynj.gov.cn/isp/ioe/ioe_all.jsp?st_service_id=NJ01GA-XK-0012#
---------------------------end-------------------------------
Java EE 5 Compatible Implementations
Sun Java System Application Server Platform Edition 9
TmaxSoft JEUS 6
1.4 Compatible Implementations
Oracle BEA WebLogic Server 9.2
Apache Geronimo 1.0-M5
CAS OnceAS2.0 Institute of Software, Chinese Academy of Sciences
Hitachi Cosminexus Application Server
IBM IBM WebSphere Application Server
JBoss JBoss Application Server 4.0
Kingdee Apusic v4.0
NEC WebOTX 6.1
ObjectWeb JOnAS v4.4
Oracle Oracle Application Server Containers for J2EE 10g (10.1.3)
Tmax Soft JEUS 5.0
NEC WebOTX 6.1
SAP NetWeaver J2EE Preview
Sun Java System Application Server Platform Edition 8
Sybase EAServer 6.0
Tmax Soft JEUS 5.0
TongTech TongWeb Application Server Version v4.6
Trifork T4 Application Server
jboss seam
http://www.redhat.com/g/JBoss_DevSuite.png
JBoss4.2.3部署SSH2
http://itcareerist.iteye.com/blog/845819
- 部署环境:JDK1.6+JBoss4.2.3+Struts2.1.8+Spring2.5.6+Hibernate3.3.2。
- 将war包解压至“JBOSS安装目录\server\default\deploy”目录下,文件夹改名为xxx.war,或者直接将war包拷贝到该目录。
- 启动JBoss,报了很多错误。主要错误摘要如下:
- Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'transactionManager' defined in class path resource [spring/applicationContext-hibernate.xml]: Cannot resolve reference to bean 'sessionFactory' while setting bean property 'sessionFactory'; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [spring/applicationContext-hibernate.xml]: Invocation of init method failed; nested exception is org.hibernate.AnnotationException: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)
- at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:275)
- .....................
- Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [spring/applicationContext-hibernate.xml]: Invocation of init method failed; nested exceptionis org.hibernate.AnnotationException: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle,org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)
- at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338)
- .....................
- Caused by: org.hibernate.AnnotationException: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)
- at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:374)
- .....................
- Caused by: java.lang.NoSuchMethodException: org.hibernate.validator.ClassValidator.<init>(java.lang.Class, java.util.ResourceBundle, org.hibernate.validator.MessageInterpolator, java.util.Map, org.hibernate.annotations.common.reflection.ReflectionManager)
- at java.lang.Class.getConstructor0(Class.java:2706)
- at java.lang.Class.getDeclaredConstructor(Class.java:1985)
- at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:362)
- ... 214 more
- 修改“JBOSS安装目录\server\default\deploy\jboss-web.deployer\META-INF”下的jboss-service.xml文件,改属性“UseJBossWebLoader”为true。
该属性原文解释如下:
A flag indicating if the JBoss Loader should be used. This loader uses a unified class loader as the class loader rather than the tomcat specific class loader.
The default is false to ensure that wars have isolated class loading for duplicate jars and jsp files.
该配置表明是否使用JBoss自身的classloader来加载webApp相关的资源;因为JBoss是通过集成Tomcat来实现Web Container的,而两者都有自己独立的classloader;
若设置为true,则表示Web应用加载时都将使用JBoss统一的classloader,即此时采用共享的扁平的UnifiedClassLoader;
若设置为false,则表示Web应用采用自己独立的WebAppClassLoader进行加载,此时Web应用和JBoss之间是完全隔离的,这也是该配置项的默认值; - 新启动正常,无错误日志,访问部署的Web应用正常。
Wildfly 8.0 版本压测异常,Wildfly 8.1 版本压测无异常,web container 自适应。商品详细场景环境压测
1、jboss的task-io的web container线程池默认为15,数据源的连接池配置Min Pool Size 为20,Max Pool Size为200.压测过程中监测数据源的连接池最多使用为17。
jboss上存在非标准cookie请求时报错,无法继续进行正常业务 / 成遥(14080241)18014822920
http://wiki.cns*****.com/pages/viewpage.action?pageId=19372357
案例:
模拟设置Cookie: quh[360]sd=sad;
请求http://127.0.0.1:8080/mmps-web/test.do
该请求中存在 request.getCookies() 获取cookie内容。
控制台报错:
Exception handling request to /mmps-web/test.do: java.lang.IllegalArgumentException: Cookie name "qh[360]sd" is a reserved token
解决方案:
添加系统属性: org.glassfish.web.rfc2109_cookie_names_enforced=false ,让jboss忽略强制检查cookie名的标准。
可以在jboss的配置文件中添加(extensions节和managment节之间):
</extensions>
<system-properties>
<property name="org.glassfish.web.rfc2109_cookie_names_enforced" value="false"/>
</system-properties>
<management>
也可以在代码层面,比如servlet初始化时。。spring context初始化时添加设置
System.setProperty("org.glassfish.web.rfc2109_cookie_names_enforced", "false");这样可以避免由于用户浏览器的cookie名存在不规范的情况导致我们的业务页面不能正常访问。
使用jstack分析cpu消耗过高的问题
http://www.iteye.com/topic/1114219
我们使用jdk自带的jstack来分析。当linux出现cpu被java程序消耗过高时,以下过程说不定可以帮上你的忙:
1.top查找出哪个进程消耗的cpu高
21125 co_ad2 18 0 1817m 776m 9712 S 3.3 4.9 12:03.24 java
5284 co_ad 21 0 3028m 2.5g 9432 S 1.0 16.3 6629:44 java
21994 mysql 15 0 449m 88m 5072 S 1.0 0.6 67582:38 mysqld
8657 co_sparr 19 0 2678m 892m 9220 S 0.3 5.7 103:06.13 java
这里我们分析21125这个java进程。
2.top中shift+h查找出哪个线程消耗的cpu高
先输入top,然后再按shift+h
21233 co_ad2 15 0 1807m 630m 9492 S 1.3 4.0 0:05.12 java
20503 co_ad2_s 15 0 1360m 560m 9176 S 0.3 3.6 0:46.72 java
21134 co_ad2 15 0 1807m 630m 9492 S 0.3 4.0 0:00.72 java
22673 co_ad2 15 0 1807m 630m 9492 S 0.3 4.0 0:03.12 java
这里我们分析21233这个线程,并且注意的是,这个线程是属于21125这个进程的。
3.jstack查找这个线程的信息
jstack [进程]|grep -A 10 [线程的16进制]
即:
- jstack 21125|grep -A 10 52f1
-A 10表示查找到所在行的后10行。21233用计算器转换为16进制52f1,注意字母是小写。
结果:
- "http-8081-11" daemon prio=10 tid=0x00002aab049a1800 nid=0x52bb in Object.wait() [0x0000000042c75000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- at java.lang.Object.wait(Object.java:485)
- at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416)
说不定可以一下子定位到出问题的代码。
可实施程度不高,明显的死循环找出来容易,遇到线程切换很频繁的应用,基笨无用。
解决案例:
并发太高,造成程序启用的http请求太多,连接池处理不了,很多http请求一直在runnable状态,造成cpu一直保持到高位。通过这种方法,就可以找出是哪些代码启用了这么多的http请求。 造成cpu飙高,很大一部分原因都是线程一直在运行或者等待造成的。如果线程切换很频繁,但每个线程都得到了很好的执行,即使cpu消耗很高,说明cpu利用率很高,程序很健康。但cpu一直保持高位甚至99%的时候,基本都是线程有问题了一直在运行。此时这些线程通过这种方法是很容易找出来的。
jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令
http://guafei.iteye.com/blog/1815222
公司内部同事分享的一篇文章
周末看到一个用jstack查看死锁的例子。昨天晚上总结了一下jstack(查看线程)、jmap(查看内存)和jstat(性能分析)命令。供大家参考
1.Jstack
1.1 jstack能得到运行java程序的java stack和native stack的信息。可以轻松得知当前线程的运行情况。如下图所示
注:这个和thread dump是同样的结果。但是thread dump是用kill -3 pid命令,还是服务器上面少用kill为妙
1.2 命名行格式
jstack [ option ] pid
jstack [ option ] executable core
jstack [ option ] [server-id@]remote-hostname-or-IP
最常用的还是jstack pid
1.3 在thread dump中,要留意下面几种状态
死锁,Deadlock(重点关注)
等待资源,Waiting on condition(重点关注)
• 等待获取监视器,Waiting on monitor entry(重点关注)
阻塞,Blocked(重点关注)
• 执行中,Runnable
• 暂停,Suspended
• 对象等待中,Object.wait() 或 TIMED_WAITING
• 停止,Parked
下面有详细的例子讲这种分析,大家参考原著
http://www.cnblogs.com/zhengyun_ustc/archive/2013/01/06/dumpanalysis.html
1.4 在thread dump中,有几种线程的定义如下
线程名称 所属 解释说明
Attach Listener JVM Attach Listener 线程是负责接收到外部的命令,而对该命令进行执行的并且吧结果返回给发送者。通常我们会用一些命令去要求jvm给我们一些反馈信息,如:java -version、jmap、jstack等等。 如果该线程在jvm启动的时候没有初始化,那么,则会在用户第一次执行jvm命令时,得到启动。
Signal Dispatcher JVM 前面我们提到第一个Attach Listener线程的职责是接收外部jvm命令,当命令接收成功后,会交给signal dispather 线程去进行分发到各个不同的模块处理命令,并且返回处理结果。 signal dispather线程也是在第一次接收外部jvm命令时,进行初始化工作。
CompilerThread0 JVM 用来调用JITing,实时编译装卸class 。 通常,jvm会启动多个线程来处理这部分工作,线程名称后面的数字也会累加,例如:CompilerThread1
Concurrent Mark-Sweep GC Thread JVM 并发标记清除垃圾回收器(就是通常所说的CMS GC)线程, 该线程主要针对于老年代垃圾回收。ps:启用该垃圾回收器,需要在jvm启动参数中加上: -XX:+UseConcMarkSweepGC
DestroyJavaVM JVM 执行main()的线程在main执行完后调用JNI中的 jni_DestroyJavaVM() 方法唤起DestroyJavaVM 线程。 JVM在 Jboss 服务器启动之后,就会唤起DestroyJavaVM线程,处于等待状态,等待其它线程(java线程和native线程)退出时通知它卸载JVM。线程退出时,都会判断自己当前是否是整个JVM中最后一个非deamon线程,如果是,则通知DestroyJavaVM 线程卸载JVM。
ps:
扩展一下:
1.如果线程退出时判断自己不为最后一个非deamon线程,那么调用thread->exit(false) ,并在其中抛出thread_end事件,jvm不退出。
2.如果线程退出时判断自己为最后一个非deamon线程,那么调用before_exit() 方法,抛出两个事件: 事件1:thread_end 线程结束事件、事件2:VM的death事件。
然后调用thread->exit(true) 方法,接下来把线程从active list卸下,删除线程等等一系列工作执行完成后,则通知正在等待的DestroyJavaVM 线程执行卸载JVM操作。
ContainerBackgroundProcessor 线程 JBOSS 它是一个守护线程, 在jboss服务器在启动的时候就初始化了,主要工作是定期去检查有没有Session过期.过期则清除.
参考:http://liudeh-009.iteye.com/blog/1584876
Dispatcher-Thread-3 线程 Log4j Log4j具有异步打印日志的功能,需要异步打印日志的Appender都需要注册到 AsyncAppender对象里面去,由AsyncAppender进行监听,决定何时触发日志打印操作。 AsyncAppender如果监听到它管辖范围内的Appender有打印日志的操作,则给这个Appender生成一个相应的event,并将该event保存在一个buffuer区域内。 Dispatcher-Thread-3线程负责判断这个event缓存区是否已经满了,如果已经满了,则将缓存区内的所有event分发到Appender容器里面去,那些注册上来的Appender收到自己的event后,则开始处理自己的日志打印工作。 Dispatcher-Thread-3线程是一个守护线程。
Finalizer线程 JVM 这个线程也是在main线程之后创建的,其优先级为10,主要用于在垃圾收集前,调用对象的finalize()方法;关于Finalizer线程的几点:
1) 只有当开始一轮垃圾收集时,才会开始调用finalize()方法;因此并不是所有对象的finalize()方法都会被执行;
2) 该线程也是daemon线程,因此如果虚拟机中没有其他非daemon线程,不管该线程有没有执行完finalize()方法,JVM也会退出;
3) JVM在垃圾收集时会将失去引用的对象包装成Finalizer对象(Reference的实现),并放入ReferenceQueue,由Finalizer线程来处理;最后将该Finalizer对象的引用置为null,由垃圾收集器来回收;
4) JVM为什么要单独用一个线程来执行finalize()方法呢?如果JVM的垃圾收集线程自己来做,很有可能由于在finalize()方法中误操作导致GC线程停止或不可控,这对GC线程来说是一种灾难;
Gang worker#0 JVM JVM 用于做新生代垃圾回收(monir gc)的一个线程。#号后面是线程编号,例如:Gang worker#1
GC Daemon JVM GC Daemon 线程是JVM为RMI提供远程分布式GC使用的,GC Daemon线程里面会主动调用System.gc()方法,对服务器进行Full GC。 其初衷是当 RMI 服务器返回一个对象到其客户机(远程方法的调用方)时,其跟踪远程对象在客户机中的使用。当再没有更多的对客户机上远程对象的引用时,或者如果引用的“租借”过期并且没有更新,服务器将垃圾回收远程对象。
不过,我们现在jvm启动参数都加上了-XX:+DisableExplicitGC配置,所以,这个线程只有打酱油的份了。
IdleRemover JBOSS Jboss连接池有一个最小值, 该线程每过一段时间都会被Jboss唤起,用于检查和销毁连接池中空闲和无效的连接,直到剩余的连接数小于等于它的最小值。
Java2D Disposer JVM 这个线程主要服务于awt的各个组件。 说起该线程的主要工作职责前,需要先介绍一下Disposer类是干嘛的。 Disposer提供一个addRecord方法。 如果你想在一个对象被销毁前再做一些善后工作,那么,你可以调用Disposer#addRecord方法,将这个对象和一个自定义的DisposerRecord接口实现类,一起传入进去,进行注册。
Disposer类会唤起“Java2D Disposer”线程,该线程会扫描已注册的这些对象是否要被回收了,如果是,则调用该对象对应的DisposerRecord实现类里面的dispose方法。
Disposer实际上不限于在awt应用场景,只是awt里面的很多组件需要访问很多操作系统资源,所以,这些组件在被回收时,需要先释放这些资源。
InsttoolCacheScheduler_
QuartzSchedulerThread Quartz InsttoolCacheScheduler_QuartzSchedulerThread是Quartz的主线程,它主要负责实时的获取下一个时间点要触发的触发器,然后执行触发器相关联的作业 。
原理大致如下:
Spring和Quartz结合使用的场景下,Spring IOC容器初始化时会创建并初始化Quartz线程池(TreadPool),并启动它。刚启动时线程池中每个线程都处于等待状态,等待外界给他分配Runnable(持有作业对象的线程)。
继而接着初始化并启动Quartz的主线程(InsttoolCacheScheduler_QuartzSchedulerThread),该线程自启动后就会处于等待状态。等待外界给出工作信号之后,该主线程的run方法才实质上开始工作。run中会获取JobStore中下一次要触发的作业,拿到之后会一直等待到该作业的真正触发时间,然后将该作业包装成一个JobRunShell对象(该对象实现了Runnable接口,其实看是上面TreadPool中等待外界分配给他的Runnable),然后将刚创建的JobRunShell交给线程池,由线程池负责执行作业。
线程池收到Runnable后,从线程池一个线程启动Runnable,反射调用JobRunShell中的run方法,run方法执行完成之后, TreadPool将该线程回收至空闲线程中。
InsttoolCacheScheduler_Worker-2 Quartz InsttoolCacheScheduler_Worker-2线程就是ThreadPool线程的一个简单实现,它主要负责分配线程资源去执行
InsttoolCacheScheduler_QuartzSchedulerThread线程交给它的调度任务(也就是JobRunShell)。
JBossLifeThread Jboss Jboss主线程启动成功,应用程序部署完毕之后将JBossLifeThread线程实例化并且start,JBossLifeThread线程启动成功之后就处于等待状态,以保持Jboss Java进程处于存活中。 所得比较通俗一点,就是Jboss启动流程执行完毕之后,为什么没有结束? 就是因为有这个线程hold主了它。 牛b吧~~
JBoss System Threads(1)-1 Jboss 该线程是一个socket服务,默认端口号为: 1099。 主要用于接收外部naming service(Jboss JNDI)请求。
JCA PoolFiller Jboss 该线程主要为JBoss内部提供连接池的托管。 简单介绍一下工作原理 :
Jboss内部凡是有远程连接需求的类,都需要实现ManagedConnectionFactory接口,例如需要做JDBC连接的
XAManagedConnectionFactory对象,就实现了该接口。然后将XAManagedConnectionFactory对象,还有其它信息一起包装到InternalManagedConnectionPool对象里面,接着将InternalManagedConnectionPool交给PoolFiller对象里面的列队进行管理。 JCA PoolFiller线程会定期判断列队内是否有需要创建和管理的InternalManagedConnectionPool对象,如果有的话,则调用该对象的fillToMin方法, 触发它去创建相应的远程连接,并且将这个连接维护到它相应的连接池里面去。
JDWP Event Helper Thread JVM
JDWP是通讯交互协议,它定义了调试器和被调试程序之间传递信息的格式。它详细完整地定义了请求命令、回应数据和错误代码,保证了前端和后端的JVMTI和JDI的通信通畅。 该线程主要负责将JDI事件映射成JVMTI信号,以达到调试过程中操作JVM的目的。
JDWP Transport Listener: dt_socket JVM 该线程是一个Java Debugger的监听器线程,负责受理客户端的debug请求。 通常我们习惯将它的监听端口设置为8787。
Low Memory Detector JVM 这个线程是负责对可使用内存进行检测,如果发现可用内存低,分配新的内存空间。
process reaper JVM 该线程负责去执行一个 OS 命令行的操作。
Reference Handler JVM JVM在创建main线程后就创建Reference Handler线程,其优先级最高,为10,它主要用于处理引用对象本身(软引用、弱引用、虚引用)的垃圾回收问题 。
Surrogate Locker Thread (CMS) JVM 这个线程主要用于配合CMS垃圾回收器使用,它是一个守护线程,其主要负责处理GC过程中,Java层的Reference(指软引用、弱引用等等)与jvm 内部层面的对象状态同步。 这里对它们的实现稍微做一下介绍:这里拿 WeakHashMap做例子,将一些关键点先列出来(我们后面会将这些关键点全部串起来):
1. 我们知道HashMap用Entry[]数组来存储数据的,WeakHashMap也不例外, 内部有一个Entry[]数组。
2. WeakHashMap的Entry比较特殊,它的继承体系结构为Entry->WeakReference->Reference 。
3. Reference 里面有一个全局锁对象:Lock,它也被称为pending_lock. 注意:它是静态对象。
4. Reference 里面有一个静态变量:pending。
5. Reference 里面有一个静态内部类:ReferenceHandler的线程,它在static块里面被初始化并且启动,启动完成后处于wait状态,它在一个Lock同步锁模块中等待。
6. 另外,WeakHashMap里面还实例化了一个ReferenceQueue列队,这个列队的作用,后面会提到。
7. 上面关键点就介绍完毕了,下面我们把他们串起来。
假设,WeakHashMap对象里面已经保存了很多对象的引用。 JVM 在进行CMS GC的时候,会创建一个ConcurrentMarkSweepThread(简称CMST)线程去进行GC,ConcurrentMarkSweepThread线程被创建的同时会创建一个SurrogateLockerThread(简称SLT)线程并且启动它,SLT启动之后,处于等待阶段。CMST开始GC时,会发一个消息给SLT让它去获取Java层Reference对象的全局锁:Lock。 直到CMS GC完毕之后,JVM 会将WeakHashMap中所有被回收的对象所属的WeakReference容器对象放入到Reference 的pending属性当中(每次GC完毕之后,pending属性基本上都不会为null了),然后通知SLT释放并且notify全局锁:Lock。此时激活了ReferenceHandler线程的run方法,使其脱离wait状态,开始工作了。ReferenceHandler这个线程会将pending中的所有WeakReference对象都移动到它们各自的列队当中,比如当前这个WeakReference属于某个WeakHashMap对象,那么它就会被放入相应的ReferenceQueue列队里面(该列队是链表结构)。 当我们下次从WeakHashMap对象里面get、put数据或者调用size方法的时候,WeakHashMap就会将ReferenceQueue列队中的WeakReference依依poll出来去和Entry[]数据做比较,如果发现相同的,则说明这个Entry所保存的对象已经被GC掉了,那么将Entry[]内的Entry对象剔除掉。
taskObjectTimerFactory JVM 顾名思义,该线程就是用来执行任务的。 当我们把一个认为交给Timer对象,并且告诉它执行时间,周期时间后,Timer就会将该任务放入任务列队,并且通知taskObjectTimerFactory线程去处理任务,taskObjectTimerFactory线程会将状态为取消的任务从任务列队中移除,如果任务是非重复执行类型的,则在执行完该任务后,将它从任务列队中移除,如果该任务是需要重复执行的,则计算出它下一次执行的时间点。
VM Periodic Task Thread JVM 该线程是JVM周期性任务调度的线程,它由WatcherThread创建,是一个单例对象。 该线程在JVM内使用得比较频繁,比如:定期的内存监控、JVM运行状况监控,还有我们经常需要去执行一些jstat 这类命令查看gc的情况,如下:
jstat -gcutil 23483 250 7 这个命令告诉jvm在控制台打印PID为:23483的gc情况,间隔250毫秒打印一次,一共打印7次。
VM Thread JVM 这个线程就比较牛b了,是jvm里面的线程母体,根据hotspot源码(vmThread.hpp)里面的注释,它是一个单例的对象(最原始的线程)会产生或触发所有其他的线程,这个单个的VM线程是会被其他线程所使用来做一些VM操作(如,清扫垃圾等)。
在 VMThread 的结构体里有一个VMOperationQueue列队,所有的VM线程操作(vm_operation)都会被保存到这个列队当中,VMThread 本身就是一个线程,它的线程负责执行一个自轮询的loop函数(具体可以参考:VMThread.cpp里面的void VMThread::loop()) ,该loop函数从VMOperationQueue列队中按照优先级取出当前需要执行的操作对象(VM_Operation),并且调用VM_Operation->evaluate函数去执行该操作类型本身的业务逻辑。
ps:VM操作类型被定义在vm_operations.hpp文件内,列举几个:ThreadStop、ThreadDump、PrintThreads、GenCollectFull、GenCollectFullConcurrent、CMS_Initial_Mark、CMS_Final_Remark….. 有兴趣的同学,可以自己去查看源文件。
(搬运自 http://blog.csdn.net/a43350860/article/details/8134234 感谢原著作者)
2.Jmap
2.1 得到运行java程序的内存分配的详细情况。例如实例个数,大小等
2.2 命名行格式
jmap [ option ] pid
jmap [ option ] executable core
jmap [ option ] [server-id@]remote-hostname-or-IP
-dump:[live,]format=b,file=<filename> 使用hprof二进制形式,输出jvm的heap内容到文件=. live子选项是可选的,假如指定live选项,那么只输出活的对象到文件.
-finalizerinfo 打印正等候回收的对象的信息.
-heap 打印heap的概要信息,GC使用的算法,heap的配置及wise heap的使用情况.
-histo[:live] 打印每个class的实例数目,内存占用,类全名信息. VM的内部类名字开头会加上前缀”*”. 如果live子参数加上后,只统计活的对象数量.
-permstat 打印classload和jvm heap长久层的信息. 包含每个classloader的名字,活泼性,地址,父classloader和加载的class数量. 另外,内部String的数量和占用内存数也会打印出来.
-F 强迫.在pid没有相应的时候使用-dump或者-histo参数. 在这个模式下,live子参数无效.
-h | -help 打印辅助信息
-J 传递参数给jmap启动的jvm.
2.3 使用例子
jmap -histo pid(查看实例)
jmap -dump:format=b,file=heap.bin pid(导出内存,据说对性能有影响,小心使用)
(format=b是通过二进制的意思,但是能不能导出文本文件我没找到,知道的告诉我)
把内存结构全部dump到二进制文件中,通过IBM的HeapAnalyzer和eclipse的MemoryAnalyzer都可以分析内存结构。
这个是我用HeapAnalyzer查看出的我们daily的内存结构,已经列出了可能存在的问题。(这个工具我不熟悉,只供大家参考)
下面是我用eclipse 的MemoryAnalyzer查看内存结构图
上面的是eclipse分析内存泄漏分析出的。这个功能点非常多。可以慢慢学习
3.Jstat
3.1 这是一个比较实用的一个命令,可以观察到classloader,compiler,gc相关信息。可以时时监控资源和性能
3.2 命令格式
-class:统计class loader行为信息
-compile:统计编译行为信息
-gc:统计jdk gc时heap信息
-gccapacity:统计不同的generations(不知道怎么翻译好,包括新生区,老年区,permanent区)相应的heap容量情况
-gccause:统计gc的情况,(同-gcutil)和引起gc的事件
-gcnew:统计gc时,新生代的情况
-gcnewcapacity:统计gc时,新生代heap容量
-gcold:统计gc时,老年区的情况
-gcoldcapacity:统计gc时,老年区heap容量
-gcpermcapacity:统计gc时,permanent区heap容量
-gcutil:统计gc时,heap情况
3.3 输出参数内容
S0 — Heap上的 Survivor space 0 区已使用空间的百分比
S0C:S0当前容量的大小
S0U:S0已经使用的大小
S1 — Heap上的 Survivor space 1 区已使用空间的百分比
S1C:S1当前容量的大小
S1U:S1已经使用的大小
E — Heap上的 Eden space 区已使用空间的百分比
EC:Eden space当前容量的大小
EU:Eden space已经使用的大小
O — Heap上的 Old space 区已使用空间的百分比
OC:Old space当前容量的大小
OU:Old space已经使用的大小
P — Perm space 区已使用空间的百分比
OC:Perm space当前容量的大小
OU:Perm space已经使用的大小
YGC — 从应用程序启动到采样时发生 Young GC 的次数
YGCT– 从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC — 从应用程序启动到采样时发生 Full GC 的次数
FGCT– 从应用程序启动到采样时 Full GC 所用的时间(单位秒)
GCT — 从应用程序启动到采样时用于垃圾回收的总时间(单位秒),它的值等于YGC+FGC
例子1
例子2(连续5次)
例子3(PGCMN显示的是最小perm的内存使用量,PGCMX显示的是perm的内存最大使用量,PGC是当前新生成的perm内存占用量,PC是但前perm内存占用量)
这个工具的参数非常多,据说基本能覆盖jprofile等收费工具的所有功能了。多用用对于系统调优还是很有帮助的
注1:我们在daily用这样命令时,都要用-F参数的。因为我们的用户都不是启动命令的用户
注2:daily的这些命令好像都没有配置到环境变量里面,这个是我在自己应用机器里面看到的。需要去jdk目录底下执行。Sudo当然是必须的了
end