posts - 23,&
comments - 3,&
trackbacks - 0
阅读排行榜
评论排行榜
win7自动升级到了ie11，但是debug工具太难用了，准备会退到9，但是在添加删除程序里，把ie11的功能关闭，安装9时，提示ie已经安装。并且ie图标也没了。。progrem files下面的ie启动程序也没了。。。。最好在这找到了卸载的办法http://www.iefans.net/windows-7-ie11-wufa-xiezai-chongxin-anzhuang-gengxin-banben/
temper 阅读(2325) |
工作中用到了struts2的tabbedpanel标签。在火狐和chrome下都没问题，但是在ie下报错：SCRIPT5007:&无法获取未定义或&null&引用的属性“toLowerCase”& &&&&&&&&&&&&&&&struts_dojo.js,&行6471&字符1。针对struts_dojo.js进行debug，发现6470行的“node.scopeName”是undefined。直接修改此js代码，增加“&&typeof(node.scopeName)!='undefined'”，重新做成struts2-dojo-plugin.jar,问题解决
temper 阅读(1479) |
JVM的-XX:[+/-]&option&以前竟然没注意，mark一个：Boolean options are turned on
with -XX:+&option& and turned off with -XX:-&option&.
temper 阅读(97) |
昨天配了两个weblogic节点，但是怎么也启动不起来。以前这种操作做了十几次了，没遇到过这种问题。错误如下：weblogic.security.SecurityInitializationException: 認証が拒否されました。起動アイデンティティが有効ではありません。起動アイデンティティ?ファイル(boot.properties)のユーザー名またはパスワード(もしくはその双方)が有効ではありません。起動アイデンティティ?ファイルが作成された後に起動アイデンティティが変更されていることが考えられます。適切な値のユーザー名およびパスワードで起動アイデンティティ?ファイルを編集および更新してください。更新された起動アイデンティティ?ファイルを使用して初めてサーバーを起動するときには、それらの値は暗号化されます。&& &at weblogic.monSecurityServiceManagerDelegateImpl.doBootAuthorization(CommonSecurityServiceManagerDelegateImpl.java:960)&& &at weblogic.monSecurityServiceManagerDelegateImpl.initialize(CommonSecurityServiceManagerDelegateImpl.java:1054)&& &at weblogic.security.service.SecurityServiceManager.initialize(SecurityServiceManager.java:873)&& &at weblogic.security.SecurityService.start(SecurityService.java:148)&& &at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)&& &at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)&& &at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)Caused By: javax.security.auth.login.FailedLoginException: [Security:090303]ユーザーweblogicの認証が失敗しました。weblogic.security.providers.authentication.LDAPAtnDelegateException: [Security:090295]予期しない例外が捕捉されました&& &at weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl.login(LDAPAtnLoginModuleImpl.java:251)&& &at mon.security.internal.service.LoginModuleWrapper$1.run(LoginModuleWrapper.java:110)&& &at java.security.AccessController.doPrivileged(Native Method)提示用户名和密码问题，但是用户名和密码我很确顶没错。然后根据这里：http://bbs.weblogicfans.net/viewthread.php?tid=399&extra=&ordertype=1&page=4增加了启动参数t3://AdminServerIP:AdminServerPort（以前都是系统默认），发现启动成功。查看startManagedWebLogic.cmd，发现41行set ADMIN_URL=XXX，竟然用的是计算机名。。。。。。。。。。。测试机装完环境，配置集群时，为了便于辨认，修改了计算机名，悲剧的根源。。。。。。然后发现stopManagedWebLogic.cmd里面用的也是计算机名。。。。。。计算机名，ip都可能被改，我感觉弄个localhost比啥都强，实在不明白这么做得原因是啥。不过以后搭建环境时，一定要先把系统要修改的做完，然后再装其他软件。
temper 阅读(1199) |
在HP-UX操作系统中使用-d32或-d64来指定使用Java应用程序使用32bit的JVM还是使用64bit的JVM(默认32bit). 一个Java应用程序运行时，它会根据自己所在的HP-UX使用的CPU类型及指定的JVM位数(-d32 or保持默认、-d64)使用$JAVA_HOME/java(壳)自动选择要执行的JVM. Itanium: $JAVA_HOME/bin/IA64N/java $JAVA_HOME/bin/IA64W/java PA-RISC: $JAVA_HOME/bin/PA_RISC/java $JAVA_HOME/bin/PA_RISC2.0/java $JAVA_HOME/bin/PA_RISC2.0W/java 目录说明 PA_RISC&&&&&&&&&&& PA_RISC 1.1 32-bit JVM PA_RISC2.0&&&&&& PA-RISC 2.0 32-bit JVM PA_RISC2.0W&&&& PA-RISC 2.0 64-bit JVM IA64N&&&&& Integrity narrow 32-bit JVM IA64W&&&& Integrity wide 64-bit JVM WebLogic Server 8.1及WebLogic Serevr 9.x and later version使用64位JVM. WebLogic Server 8.1: 修改${Domain_home}下的startWebLogic.sh和startManagedWebLogic.sh中两个脚本的MEM_ARGS参数值，在此参数值的最前面加上-64参数即可，例如: MEM_ARGS=”-d64 –Xms512m –Xmx1024m…” WebLogic Serevr 9.x and later version: 修改${Domain_home}/bin/下的setDomainEnv.sh脚本MEM_ARGS参数值，在此参数值的最前面加上-64参数即可。 转载自
temper 阅读(824) |
最近的项目涉及到了JAVA需要调用C程序的问题。主要是调用C写的加密算法。 主要解决方案是应用JNI去调用C生成的so库 用eclispe新建一个java project项目,项目名称为spidHandle，注意下面VC的项目名称也是spidHandle，他们分别是用eclispe和VC6.0创建的，不是同个项目。 编写一个JNI入口类SpidHandle.java： Java代码 &package&com.spidHandle.&&public&class&SpidHandle&{&&&&&&&&&&static&{&&&&&&&&&&&&&&&&&&System.loadLibrary("spidhandle");&&&&&&&&&&}&&&&&&&&&&&&&&&&&&&&public&String&buildSpID(String&path,&String&login_name,&String&password,&String&key)&&&&&&&&&&{&&&&&&&&&&&&&&return&getSPID(path,&login_name,&password,&key);&&&&&&&&&&}&&&&&&&&&&&&&&&&&&&&public&native&String&getSPID(String&path,&String&login_name,&String&password,&String&key);&&&&&&&&/**&&&&&&*&@param&args&&&&&&*&&&&&&&*&供测试用&&&&&&*/&&&&&&public&static&void&main(String[]&args)&{&&&&&&&&&&//&TODO&Auto-generated&method&stub&&&&&&&&&&String&keyforMD5&=&"A6EIo8tuaKS";&&&&&&&&&&String&s&=&new&SpidHandle().buildSpID("/test",&"test",&"test",&keyforMD5);&&&&&&&&&&System.out.println(s);&&&&&&}&&&&}&&
通过CMD命令窗口，CMD命令窗口定位到SpidHandle.java的目录下，编译SpidHandle.java文件： Java代码 &javac&SpidHandle.java&& 执行JAVAC命令后，在同个文件目录下生成SpidHandle.class 将CMD窗口退回到包的根目录下，如spidHandle工程路径为： Z:\project\work_workspace\spidhandle 其中通过编译后的SpidHandle.class存在于目录下： Z:\project\work_workspace\spidhandle\src\com\spidHandle\api 由于SpidHandle类所在的包是com.spidHandle.api，所以CMD命令窗口要退回到Z:\project\work_workspace\spidhandle\src目录 然后在CMD窗口中执行 Java代码 &javah&com.spidHandle.api.SpidHandle&& 执行后在Z:\project\work_workspace\spidhandle\src目录下生成文件 com_spidHandle_api_SpidHandle.h文件。 安装VC6.0开发工具。如果你是在windows下开发,那可以先生成DLL,这样你就可以在Windows下调试。其实JNI调用DLL和SO是一样的，只是运行的操作系统不一样而已。下面是如何用VC6.0创建一个DLL项目。 创建一个项目工程，名为spidhandle的工程，创建过程如下： 1、打开VC6.0-&文件-&新建 2、在弹出窗口中的工程选项卡中选择Win32 Dynamic-Link L工程名命名为点击确定。 3、在新的提示窗口中选择一个空白的DLL工程，点击完成。 4、在菜单的工具栏中选择选项，弹出选项窗口。切换到目录选项卡 5、在目录选项卡中新建目录，新建的目录为你JDK所在的目录下的include目录，如： && D:\Program Files\Java\jdk1.6.0_16\include & 再新建一个目录，新建的目录为include文件夹下的win32目录，如 && D:\Program Files\Java\jdk1.6.0_16\include\win32 & 此步主要是向工程引入jni所需要的头文件，如include中包含了jni.h,jni_md.h 6、将com_spidHandle_api_SpidHandle.h头文件拷贝到vc6.0工程spidHandle根目录下，将其添加到工 程的Header Files，右键工程窗口中的Header
Files,选择添加文件到目录下，选择工程路径下的com_spidHandle_api_SpidHandle.h文件。 7、在spidHandle工程根目录的文件夹中新建com_spidHandle_api_SpidHandle.h头文件对应的cpp文件， 文件名称为com_spidHandle_api_SpidHandle.cpp,然后返回VC6.0操作界面，将其添加到工程的Source
Files,右键工程窗口中的Source
Files,选择添加文件到目录下，选择工程路径下的com_spidHandle_api_SpidHandle.cpp文件。 Java代码 &#include&"com_spidHandle_api_SpidHandle.h"&&#include&&string.h&&&&&#include&"MD5.h"&&&&const&static&char*&version&=&"1201.01";&&&&JNIEXPORT&jstring&JNICALL&Java_com_spidHandle_api_SpidHandle_getSPID&&&(JNIEnv&*env&,&jobject&obj,&jstring&path,&jstring&login_name,&jstring&password,&jstring&key)&&{&&&&&&printf("-=&com_spidHandle_api_SpidHandle&Version&&%s&=-&\n",&version);&&&&&&char&icpid[256];&&&&&&const&char&*&md5="A6EIo8tuaKS";&&&&&&&&const&char*&login_user&=&env-&GetStringUTFChars(login_name,&false);&&&&&&const&char*&login_pwd&=&env-&GetStringUTFChars(password,&false);&&&&&&const&char*&md5_key&=&env-&GetStringUTFChars(key,&false);&&&&&&const&char*&path_str&=&env-&GetStringUTFChars(path,&false);&&&&&&&&&&&&memset(icpid,&0,&256);&&&&&&&&printf("login_user&=&%s\n",&login_user);&&&&&&printf("path&=&%s\n",&path_str);&&&&&&printf("login_pwd&=&%s\n",&login_pwd);&&&&&&printf("md5_key&=&%s\n",&md5_key);&&&&&&&&&&//&不管播放哪个url&直接用这个加密&&-_-||&&&&&&&//&pPath&=&"tmes_224";&&&&&&//&组建加密部分&&&&&&char&*p=&&&&&&*p=strlen(login_user);&&&&&&p++;&&&&&&strcpy(p,login_user);&&&&&&p+=strlen(login_user);&&&&&&*p=strlen(path_str);&&&&&&p++;&&&&&&strcpy(p,path_str);&&&&&&p+=strlen(path_str);&&&&&&&&&&&&if(strlen(md5_key)&&&1)&&&&&&&&&&md5&=&md5_&&&&&&*p=strlen(md5);&&&&&&p++;&&&&&&strcpy(p,md5);&&&&&&p+=strlen(md5);&&&&&&&&MD5&m1;&&&&&&m1&&&&md5&&&&login_user&&&&login_&&&&&&&&const&char&*pmd5&=&m1.HexDigest();&&//&symbian专用&&&&&&char&md5buf[256];&&&&&&memset(md5buf,0,256);&&&&&&memcpy(&md5buf,pmd5,strlen(pmd5)&);&//&结束symbian专用&&&&&&&&printf("md5buf&=&%s\n",&md5buf);&&&&&&&&&&&&int&pmd5_len&=&strlen(pmd5);&&&&&&&&*p=strlen(md5buf);&&&&&&p++;&&&&&&strcpy(p,md5buf);&&&&&&p+=strlen(md5buf);&&&&&&&&printf("spid&=&%s\n",&icpid);&&&&&&&&return&env-&NewStringUTF(icpid);&&}&& 8、将MD5.h,MD5.cpp拷贝到工程目录下，即跟com_spidHandle_api_SpidHandle.h文件同在项目根目录下。这两个文件其实是我用到的加密类。不是VC自有的，是另外同事开发的。 9、在VC6.0的菜单栏中选择组建；在工程文件夹下的Debug文件夹中生成spidHandle.dll 10、可以将spidHandle.dll拷贝到JAVA
PROJECT的spidHandle的项目里，放在项目的根目录，即Z:\project\work_workspace\spidhandle目录 下，用eclispe运行SpidHandle.java文件。在输出窗口中会打印com_spidHandle_api_SpidHandle.cpp 的printf输出部分。
生成so文件，此步需要在linux上操作。 1、将com_spidHandle_api_SpidHandle.h, MD5.h,com_spidHandle_api_SpidHandle.cpp,MD5.cpp文件拷贝到linux下，如拷贝到/home/spidHandle目录中去； 2、在linux下，命令切换到spidHandle文件夹下，执行： g++ com_spidHandle_api_SpidHandle.cpp MD5.cpp
-I/usr/java/jdk1.6.0_16/include -I/usr/java/jdk1.6.0_16/include/linux
-fPIC -shared -o libspidhandle.so 命令。其中-I/usr/java/jdk1.6.0_16/include
-I/usr/java/jdk1.6.0_16/include/linux 表示需要引入的头文件。相当于生成DLL引入了jni.h等文件。-fPIC表示生成共享库文件，libspidhandle.so表示库文件名。 3、执行export LD_LIBRARY_PATH=/home/spidHandle & 此步是设置将库文件所在路径加入LD_LIBRARY_PATH中去，如果不执行此步，在运行中就会出现异常： Java代码 &java.lang.UnsatisfiedLinkError:&no&XXX&in&java.library.path&& 4、可以在Linux中部署一个简单的web 应用，如一个简单的test项目，在servlet中调用该so，调用代码如下： Java代码 &String&spid&=&new&SpidHandle().buildSpID(pathforMD5,&user,pwd,keyforMD5);&& spid为加密后返回的结果。
补充： 过程中所碰到的问题：
问题1 java.lang.UnsatisfiedLinkError: /home/spidhandle/libspidhandle.so:
/home/spidhandle/libspidhandle.so: wrong ELF class: ELFCLASS64 (Possible
cause: architecture word width mismatch)
在linux中，用servlet调用该so,出现上面的异常，主要因为我所部署应用的linux服务器是64位的，而所生成的so是32位的，后来将项目部署到32位的服务器上就解决问题了。 如何查看linux操作系统是32位还是64位的，可以运行下面命令： 查看操作系统位数 Java代码 &file&/bin/ls&&
问题2 运行servlet，JVM崩溃，并输出JVM异常，异常文件在tomcat启动文件startup.sh同个目录下，如tomcat/bin下，文件格式为hs_err_pid*.log 如，hs_err_pid23600.log 错误日志内容： # # A fatal error has been detected by the Java Runtime Environment: # #& SIGSEGV (0xb) at pc=0xb6e5a1ef, pid=23600, tid= # # JRE version: 6.0_16-b01 # Java VM: Java HotSpot(TM) Server VM (14.2-b01 mixed mode linux-x86 ) # Problematic frame: # V& [libjvm.so+0x3931ef] # # If you would like to submit a bug report, please visit: #&& /webapps/bugreport/crash.jsp #
---------------& T H R E A D& ---------------
Current thread (0x085bbc00):& JavaThread "http-8080-1" daemon [_thread_in_vm, id=23622, stack(0x90e1a000,0x90e6b000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x
Registers: EAX=0x, EBX=0xb71dd7c0, ECX=0xb71f87e0, EDX=0x00000ffc ESP=0x90e696d4, EBP=0x90e69748, ESI=0x, EDI=0x00090e69 EIP=0xb6e5a1ef, CR2=0x, EFLAGS=0x
Top of Stack: (sp=0x90e696d4) 0x90e696d4:&& b71d5ec8 e5a127 b7783a30 0x90e696e4:&& b00
0x90e696f4:&& 080de058 080de060 080de44c 085bbc00 0x90e69704:&& d8ff4 bbc00 0x90e69714:&& 90e6f56
085bbc00 0x90e69724:&& 00 90dd6601 0x90e69734:&& 90dd4 90dd9ff4 927ec5f4 0x90e69744:&& 085bbc00 90efbd 085bbd10
Instructions: (pc=0xb6e5a1ef) 0xb6e5a1df:&& ac 8b 46 08 89 45 b0 8b 46 0c 89 45 b4 8b 45 0c 0xb6e5a1ef:&& 8b 00 50 e8 09 ae fd ff 83 ec 0c 89 c7 50 e8 aa
Stack: [0x90e1a000,0x90e6b000],& sp=0x90e696d4,& free space=317k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V& [libjvm.so+0x3931ef] C& [libspidhandle.so+0xfbd]& _ZN7JNIEnv_17GetStringUTFCharsEP8_jstringPh+0x27 C& [libspidhandle.so+0xc6e]& Java_com_spidHandle_api_SpidHandle_getSPID+0x52 j&
com.spidHandle.api.SpidHandle.getSPID(Ljava/lang/SLjava/lang/SLjava/lang/SLjava/lang/S)Ljava/lang/S+0 j&
com.spidHandle.api.SpidHandle.buildSpID(Ljava/lang/SLjava/lang/SLjava/lang/SLjava/lang/S)Ljava/lang/S+6 j& com.play.servlet.PlayServlet.service(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+1044 j&
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+376 j& org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+101 j&
org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+804 j&
org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+365 j&
org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+64 j&
org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+6 j&
org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+42 j& org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/RLorg/apache/coyote/R)V+158 j& org.apache.coyote.http11.Http11Processor.process(Ljava/net/S)V+514 j& org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ljava/net/S)Z+82 j& org.apache.tomcat.util.net.JIoEndpoint$Worker.run()V+41 j& java.lang.Thread.run()V+11 v& ~StubRoutines::call_stub V& [libjvm.so+0x36ca20] V& [libjvm.so+0x530828] V& [libjvm.so+0x36c227] V& [libjvm.so+0x36c2da] V& [libjvm.so+0x3e95f5] V& [libjvm.so+0x61097e] V& [libjvm.so+0x531cce] C& [libpthread.so.0+0x6725]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j&
com.spidHandle.api.SpidHandle.getSPID(Ljava/lang/SLjava/lang/SLjava/lang/SLjava/lang/S)Ljava/lang/S+0 j&
com.spidHandle.api.SpidHandle.buildSpID(Ljava/lang/SLjava/lang/SLjava/lang/SLjava/lang/S)Ljava/lang/S+6 j& com.play.servlet.PlayServlet.service(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+1044 j&
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+376 j& org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRLjavax/servlet/ServletR)V+101 j&
org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+804 j&
org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+365 j&
org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+64 j&
org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+6 j&
org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/RLorg/apache/catalina/connector/R)V+42 j& org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/RLorg/apache/coyote/R)V+158 j& org.apache.coyote.http11.Http11Processor.process(Ljava/net/S)V+514 j& org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ljava/net/S)Z+82 j& org.apache.tomcat.util.net.JIoEndpoint$Worker.run()V+41 j& java.lang.Thread.run()V+11 v& ~StubRoutines::call_stub
---------------& P R O C E S S& ---------------
Java Threads: ( =& current thread ) =&0x085bbc00 JavaThread "http-8080-1" daemon [_thread_in_vm, id=23622, stack(0x90e1a000,0x90e6b000)] & 0x912ecc00 JavaThread "TP-Monitor" daemon [_thread_blocked, id=23619, stack(0x90e6b000,0x90ebc000)] & 0x91069c00 JavaThread "TP-Processor4" daemon [_thread_in_native, id=23618, stack(0x90ebc000,0x90f0d000)] & 0x JavaThread "TP-Processor3" daemon [_thread_blocked, id=23617, stack(0x90f0d000,0x90f5e000)] & 0x JavaThread "TP-Processor2" daemon [_thread_blocked, id=23616, stack(0x90f5e000,0x90faf000)] & 0x912ea400 JavaThread "TP-Processor1" daemon [_thread_blocked, id=23615, stack(0x90faf000,0x)] & 0x912da000 JavaThread "http-8080-Acceptor-0" daemon [_thread_in_native, id=23614, stack(0xx)] & 0x JavaThread
"ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon
[_thread_blocked, id=23613, stack(0xx911de000)] & 0x912ac400 JavaThread "GC Daemon" daemon [_thread_blocked, id=23612, stack(0xx)] & 0x91615c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=23610, stack(0xx)] & 0x91613c00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=23609, stack(0xx914ef000)] & 0x JavaThread "CompilerThread0" daemon [_thread_blocked, id=23608, stack(0x914ef000,0x)] & 0x JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=23607, stack(0xx915c1000)] & 0x JavaThread "Finalizer" daemon [_thread_blocked, id=23606, stack(0xx)] & 0x080d8400 JavaThread "Reference Handler" daemon [_thread_blocked, id=23605, stack(0xx917b1000)] & 0x JavaThread "main" [_thread_in_native, id=23601, stack(0xb6a4e000,0xb6a9f000)]
Other Threads: & 0x080d4400 VMThread [stack: 0x917b32000] [id=23604] & 0x WatcherThread [stack: 0xx] [id=23611]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
PSYoungGen&&&&& total 24448K, used 339K [0xbxb1da00000) & eden space 23168K, 1% used [0xbxbxb1ac0000) & from space 1280K, 0% used [0xb1ccd60000) & to&& space 1408K, 0% used [0xb1acacc20000)
PSOldGen&&&&&&& total 27072K, used 8597K [0x95d0720000) & object space 27072K, 31% used [0x95d70000)
PSPermGen&&&&&& total 19200K, used 11186K [0x91d0fcd00000) & object space 19200K, 58% used [0x91dec980,0x92fc0000)
Dynamic libraries: 52000 r-xp :03 5775425&&& /usr/java/jdk1.6.0_16/bin/java 53000 rwxp :03 5775425&&& /usr/java/jdk1.6.0_16/bin/java c64000 rwxp :00 0&&&&&&&&& [heap] 90cac000-90cb9000 r-xp :03 && /lib/libgcc_s.so.1 90cb9000-90cba000 r-xp :03 && /lib/libgcc_s.so.1 90cba000-90cbb000 rwxp :03 && /lib/libgcc_s.so.1 90cbb000-90da3000 r-xp :03 5337022&&& /usr/lib/libstdc++.so.6.0.10 90da00 r-xp 000e 5337022&&& /usr/lib/libstdc++.so.6.0.10 90da00 rwxp 000eb000 08:03 5337022&&& /usr/lib/libstdc++.so.6.0.10 90da8000-90dae000 rwxp :00 0
90dd00 r-xp :03 && /home/play/lib/libspidhandle.so 90dd9000-90dda000 r-xp :03 && /home/play/lib/libspidhandle.so 90dda000-90ddb000 rwxp :03 && /home/play/lib/libspidhandle.so 90ddb000-90ddc000 r-xs :03 5808917&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/spidhandle.jar 90ddc000-90ddd000 r-xs :03 5808916&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/slf4j-simple-1.5.8.jar 90ddd000-90ddf000 r-xs :03 5808915&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/slf4j-api-1.5.6.jar 90ddf000-90de5000 r-xs :03 5808914&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/logback-core-0.9.15.jar 90de5000-90dea000 r-xs :03 5808913&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/logback-classic-0.9.15.jar 90dea000-90df1000 r-xs :03 5808912&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/log4j-1.2.15.jar 90df1000-90dfd000 r-xs 000a 5808911&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jxl.jar 90dfd000-90e07000 r-xs :03 5808910&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jstl-1.2.jar 90ea000 r-xs :03 5808909&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jsf-impl.jar 90e1a000-90e1d000 ---p :00 0
90e1d000-90e6b000 rwxp :00 0&&&&&&&&& [threadstack:] 90e6b000-90e6e000 ---p :00 0
90e6e000-90ebc000 rwxp :00 0
90ebc000-90ebf000 ---p :00 0
90ebf000-90f0d000 rwxp :00 0
90f0d000-90f10000 ---p :00 0
90fe000 rwxp :00 0
90f5e000-90f61000 ---p :00 0
90f61000-90faf000 rwxp :00 0
90faf000-90fb2000 ---p :00 0
90fb0 rwxp :00 0
b3000 rwxp :00 0
910b0 ---p :00 0
05000 r-xs :03 5808908&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jsf-api.jar 07000 r-xs :03 5808907&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/commons-logging-1.1.1.jar 3c000 r-xs :03 && /var/run/nscd/dbl5FOXp (deleted) 3f000 ---p :00 0
8d000 rwxp :00 0
90000 ---p :00 0
de000 rwxp :00 0
911de000-911f1000 r-xp :03 5784005&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libnet.so 911f0 rwxp :03 5784005&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libnet.so 911f0 r-xs :03 5783936&&& /usr/java/jdk1.6.0_16/jre/lib/ext/sunjce_provider.jar 911f0 r-xs :03 5784036&&& /usr/java/jdk1.6.0_16/jre/lib/jsse.jar 911fc000- r-xs :03 5783937&&& /usr/java/jdk1.6.0_16/jre/lib/ext/sunpkcs11.jar f8000 rwxp :00 0
912f0 ---p :00 0
02000 r-xs :03 5808906&&& /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/commons-codec-1.3.jar 05000 r-xs :03 5784024&&& /usr/java/jdk1.6.0_16/jre/lib/jce.jar 08000 ---p :00 0
56000 rwxp :00 0
59000 r-xs 000cb000 08:03 5783821&&& /usr/java/jdk1.6.0_16/jre/lib/ext/localedata.jar 5d000 r-xs :03 5808320&&& /usr/apache-tomcat-6.0.32/lib/catalina-tribes.jar 60000 r-xs :03 5808331&&& /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-es.jar 6a000 r-xs 000b 5808329&&& /usr/apache-tomcat-6.0.32/lib/tomcat-coyote.jar 71000 r-xs :03 5808325&&& /usr/apache-tomcat-6.0.32/lib/jasper.jar 80000 r-xs :03 5808321&&& /usr/apache-tomcat-6.0.32/lib/catalina.jar 82000 r-xs :03 5808319&&& /usr/apache-tomcat-6.0.32/lib/catalina-ha.jar 86000 r-xs :03 5808330&&& /usr/apache-tomcat-6.0.32/lib/tomcat-dbcp.jar 88000 r-xs :03 5808318&&& /usr/apache-tomcat-6.0.32/lib/catalina-ant.jar 8a000 r-xs :03 5808323&&& /usr/apache-tomcat-6.0.32/lib/el-api.jar 8c000 r-xs :03 5808328&&& /usr/apache-tomcat-6.0.32/lib/servlet-api.jar 9a000 r-xs :03 5808322&&& /usr/apache-tomcat-6.0.32/lib/ecj-3.3.1.jar 9c000 r-xs :03 5808333&&& /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-ja.jar 9d000 ---p :00 0
1d000 rwxp :00 0
20000 ---p :00 0
6e000 rwxp :00 0
71000 ---p :00 0
ef000 rwxp :00 0
914ef000-914f2000 ---p :00 0
914f0 rwxp :00 0
73000 ---p :00 0
c1000 rwxp :00 0
915c0 r-xp :03 5546089&&& /usr/lib/locale/en_US.utf8/LC_CTYPE ff000 rwxp :00 0
916ff000- ---p :00 0
01000 rwxp :00 0
03000 r-xs :03 5808326&&& /usr/apache-tomcat-6.0.32/lib/jsp-api.jar 05000 r-xs :03 5808332&&& /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-fr.jar 08000 r-xs :03 5808324&&& /usr/apache-tomcat-6.0.32/lib/jasper-el.jar 0e000 r-xp :03 5784001&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libmanagement.so 0f000 rwxp :03 5784001&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libmanagement.so 12000 ---p :00 0
60000 rwxp :00 0
63000 ---p :00 0
b1000 rwxp :00 0
917b0 ---p :00 0
917b0 rwxp :00 0
fb000 r-xs 02fb 5784038&&& /usr/java/jdk1.6.0_16/jre/lib/rt.jar 919fb000-919fc000 ---p :00 0
919fc000-91a7c000 rwxp :00 0
91a7c000-91a7d000 ---p :00 0
91a7d000-91b07000 rwxp :00 0
91bd000 rwxp :00 0
91b1d000-91b2b000 rwxp :00 0
91b2b000-91bf1000 rwxp :00 0
91bf1000-91bfb000 rwxp :00 0
91bfb000-91c11000 rwxp :00 0
91cf000 rwxp :00 0
91c1f000-91ce4000 rwxp :00 0
91ce00 rwxp :00 0
91cf2000-91cff000 rwxp :00 0
91cff000-92fc0000 rwxp :00 0
92fc00 rwxp :00 0
95d00 rwxp :00 0
20000 rwxp :00 0
bda0000 rwxp :00 0
b1da0 rwxp :00 0
b01000 r-xs :03 5808317&&& /usr/apache-tomcat-6.0.32/lib/annotations-api.jar b02000 r-xs :03 5808298&&& /usr/apache-tomcat-6.0.32/bin/tomcat-juli.jar b03000 r-xs :03 5808288&&& /usr/apache-tomcat-6.0.32/bin/commons-daemon.jar b0a000 r-xs :03 5523095&&& /usr/lib/gconv/gconv-modules.cache b390a000-b3913000 rwxp :00 0
bca000 rwxp :00 0
b39ca000-b3c0a000 rwxp :00 0
b3c0a000-b69ca000 rwxp :00 0
b69ca000-b69d9000 r-xp :03 5784014&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libzip.so b69d0 rwxp :03 5784014&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libzip.so b69db000-b69e3000 rwxs :03 6743707&&& /tmp/hsperfdata_root/23600 b69e00 r-xs :03 && /var/run/nscd/passwd b6a1e000 r-xp :03 5784018&&& /usr/java/jdk1.6.0_16/jre/lib/i386/native_threads/libhpi.so b6a1e000-b6a1f000 rwxp :03 5784018&&& /usr/java/jdk1.6.0_16/jre/lib/i386/native_threads/libhpi.so b6a1f000-b6a42000 r-xp :03 5783990&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libjava.so b6a400 rwxp :03 5783990&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libjava.so b6a4c000 r-xp :03 && /lib/librt-2.11.1.so b6a4c000-b6a4d000 r-xp :03 && /lib/librt-2.11.1.so b6a4d000-b6a4e000 rwxp :03 && /lib/librt-2.11.1.so b6a4e000-b6a51000 ---p :00 0
b6a5f000 rwxp :00 0
b6a9f000-b6ac5000 r-xp :03 && /lib/libm-2.11.1.so b6ac00 r-xp :03 && /lib/libm-2.11.1.so b6ac00 rwxp :03 && /lib/libm-2.11.1.so b6ac0 r-xp :03 5784022&&& /usr/java/jdk1.6.0_16/jre/lib/i386/server/libjvm.so be2000 rwxp 006cc000 08:03 5784022&&& /usr/java/jdk1.6.0_16/jre/lib/i386/server/libjvm.so b71e0 rwxp :00 0
b60000 r-xp :03 && /lib/libc-2.11.1.so b62000 r-xp :03 && /lib/libc-2.11.1.so b63000 rwxp :03 && /lib/libc-2.11.1.so b67000 rwxp :00 0
b6a000 r-xp :03 && /lib/libdl-2.11.1.so b776a000-b776b000 r-xp :03 && /lib/libdl-2.11.1.so b776b000-b776c000 rwxp :03 && /lib/libdl-2.11.1.so b776c000-b7773000 r-xp :03 5783973&&& /usr/java/jdk1.6.0_16/jre/lib/i386/jli/libjli.so b75000 rwxp :03 5783973&&& /usr/java/jdk1.6.0_16/jre/lib/i386/jli/libjli.so b8c000 r-xp :03 && /lib/libpthread-2.11.1.so b778c000-b778d000 r-xp :03 && /lib/libpthread-2.11.1.so b778d000-b778e000 rwxp :03 && /lib/libpthread-2.11.1.so b778e000-b7790000 rwxp :00 0
b91000 r-xs :03 5808283&&& /usr/apache-tomcat-6.0.32/bin/bootstrap.jar b92000 rwxp :00 0
b93000 r-xp :00 0
ba8000 r-xp :03 && /lib/libnsl-2.11.1.so b77a0 r-xp :03 && /lib/libnsl-2.11.1.so b77a0 rwxp :03 && /lib/libnsl-2.11.1.so b77aa000-b77ac000 rwxp :00 0
b77ac000-b77b7000 r-xp :03 5784013&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libverify.so b77b0 rwxp :03 5784013&&& /usr/java/jdk1.6.0_16/jre/lib/i386/libverify.so b77b0 rwxp :00 0
b77b0 r-xp :03 && /lib/ld-2.11.1.so b77d0 r-xp :03 && /lib/ld-2.11.1.so b77d0 rwxp :03 && /lib/ld-2.11.1.so bfcc6000-bfcdb000 rwxp :00 0&&&&&&&&& [stack] ffffe000-fffff000 r-xp :00 0&&&&&&&&& [vdso]
VM Arguments: jvm_args:
-Djava.util.logging.config.file=/usr/apache-tomcat-6.0.32/conf/logging.properties
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.endorsed.dirs=/usr/apache-tomcat-6.0.32/endorsed
-Dcatalina.base=/usr/apache-tomcat-6.0.32
-Dcatalina.home=/usr/apache-tomcat-6.0.32
-Djava.io.tmpdir=/usr/apache-tomcat-6.0.32/temp
java_command: org.apache.catalina.startup.Bootstrap start Launcher Type: SUN_STANDARD
Environment Variables: JAVA_HOME=/usr/java/jdk1.6.0_16 CLASSPATH=/usr/apache-tomcat-6.0.32/bin/bootstrap.jar PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin:/usr/games:/usr/lib/mit/bin:/usr/lib/mit/sbin:/usr/java/jdk1.6.0_16/bin:/usr/java/jdk1.6.0_16/jre/bin LD_LIBRARY_PATH=/usr/java/jdk1.6.0_16/jre/lib/i386/server:/usr/java/jdk1.6.0_16/jre/lib/i386:/usr/java/jdk1.6.0_16/jre/../lib/i386:/home/play/lib SHELL=/bin/bash HOSTTYPE=i386 OSTYPE=linux MACHTYPE=i686-suse-linux
Signal Handlers: SIGSEGV: [libjvm.so+0x650710], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGBUS: [libjvm.so+0x650710], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGFPE: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGPIPE: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGXFSZ: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGILL: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGUSR1: SIG_DFL, sa_mask[0]=0x, sa_flags=0x SIGUSR2: [libjvm.so+0x5321f0], sa_mask[0]=0x, sa_flags=0x SIGHUP: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGINT: SIG_IGN, sa_mask[0]=0x, sa_flags=0x SIGTERM: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x SIGQUIT: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x
---------------& S Y S T E M& ---------------
OS:SUSE Linux Enterprise Server 11 (i586) VERSION = 11 PATCHLEVEL = 1
uname:Linux 2.6.32.12-0.7-pae #1 SMP
11:14:20 + libc:glibc 2.11.1 NPTL 2.11.1
rlimit: STACK 8192k, CORE 1k, NPROC 15118, NOFILE 8192, AS 3192000k load average:0.00 0.04 0.05
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 23 stepping 10, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 3752k free), swap 40564k free)
vm_info: Java HotSpot(TM) Server VM (14.2-b01) for linux-x86 JRE
(1.6.0_16-b01), built on Jul 31 :51 by "java_re" with gcc
3.2.1-7a (J2SE release)
time: Sat Mar 12 17:13:08 2011 elapsed time: 27 seconds
一开始以为是JVM无法释放C的对象，但后来发现 Java代码 &Heap&&&PSYoungGen&&&&&&total&24448K,&used&339K&[0xbxb1da00000)&&&&eden&space&23168K,&1%&used&[0xbxbxb1ac0000)&&&&from&space&1280K,&0%&used&[0xb1ccd60000)&&&&to&&&space&1408K,&0%&used&[0xb1acacc20000)&&&PSOldGen&&&&&&&&total&27072K,&used&8597K&[0x95d0720000)&&&&object&space&27072K,&31%&used&[0x95d70000)&&&PSPermGen&&&&&&&total&19200K,&used&11186K&[0x91d0fcd00000)&&&&object&space&19200K,&58%&used&[0x91dec980,0x92fc0000)&&
并没有出现堆栈缢出的现象，所以排除该原因。
查阅 文档:
&&&&& JavaTM 2 Platform, Standard Edition 5.0 &&&&& Troubleshooting and Diagnostic Guide
&&&&& 文档中提到: &&&&&
&&&&& If you get a crash in a native application library (like the above examples) then you may be able to &&&&& attach the native debugger (dbx, gdb, windbg depending on the operating system) to the core file/crash &&&&& dump if it is available. Another approach is run with the -Xcheck:jni option added to the command &&&&& line (section 1.17.3). The -Xcheck:jni option is not guaranteed to find all issues with JNI code but it &&&&& can help identify a significant number of issues. &&&&&
&&&&& 解决方法: &&&&& 启动JVM时增加启动参数 -Xcheck:jni &&&&& 日志中输出JNI的错误日志: &&&&& Java代码 &FATAL&ERROR&in&native&method:&JNI&string&operation&received&a&non-string&&at&com.spidHandle.api.SpidHandle.getSPID(Native&Method)&&at&com.spidHandle.api.SpidHandle.buildSpID(SpidHandle.java:12)&&at&com.play.servlet.PlayServlet.service(PlayServlet.java:190)&&at&org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)&&at&org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)&&at&org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)&&at&org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)&&at&org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)&&at&org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)&&at&org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)&&at&org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)&&at&org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)&&at&org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)&&at&org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)&&at&java.lang.Thread.run(Thread.java:619) JVM崩溃的原因找到了.是由于传入C方法体中某个参数值为NULL，如buildSpID(String path, String
login_name, String password, String
key)中login_name为NULL,导致传递给C程序的参数为NULL.NULL值传递给C,C不能识别他为字符串,所以JVM崩溃.
temper 阅读(4012) |
今天客户发过来一个新的jar包B.jar，让我替换原来的进行测试，但是替换完毕执行后，出现如下错误：C:\Program Files\Java\jdk1.5.0_16Exception in thread "main" java.lang.SecurityException: class "xx.xx"'s signer information does not match signer information of other classes in the same package&&&&&&& at java.lang.ClassLoader.checkCerts(ClassLoader.java:775)&&&&&&& at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487)&&&&&&& at java.lang.ClassLoader.defineClass(ClassLoader.java:614)&&&&&&& at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)&&&&&&& at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)&&&&&&& at java.net.URLClassLoader.access$100(URLClassLoader.java:56)&&&&&&& at java.net.URLClassLoader$1.run(URLClassLoader.java:195)&&&&&&& at java.security.AccessController.doPrivileged(Native Method)&&&&&&& at java.net.URLClassLoader.findClass(URLClassLoader.java:188)&&&&&&& at java.lang.ClassLoader.loadClass(ClassLoader.java:306)&&&&&&& at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)&&&&&&& at java.lang.ClassLoader.loadClass(ClassLoader.java:251)&&&&&&& at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)&&&&&&& at xx.xx(xx.java:80)网上搜了一圈，大部分说引入的jar包呢有相同类名的类，所以loader的时候出现错误。但是目前做的一个小产品，只有两个jar包，A.jar和前文提到的B.jar，没有引入第三方包。我仔细查了一下两个jar包，不存在相同类名的情况。最后发现这个问题很多时候和数字签名这个关键字一起出现。然后仔细检查，发现新的B.jar里面忘记加数字签名了。把A.jar里面的数字签名删除，运行正常。目前在等待加完数字签名的B.jar,也在查资料寻找出现此问题的原因，未完待续。
temper 阅读(2846) |
temper 阅读(3310) |
Java 语言中的 volatile 变量可以被看作是一种 “程度较轻的 synchronized”；与 synchronized 块相比，volatile 变量所需的编码较少，并且运行时开销也较少，但是它所能实现的功能也仅是 synchronized 的一部分。本文介绍了几种有效使用 volatile 变量的模式，并强调了几种不适合使用 volatile 变量的情形。
锁提供了两种主要特性：互斥（mutual exclusion） 和可见性（visibility）。互斥即一次
只允许一个线程持有某个特定的锁，因此可使用该特性实现对共享数据的协调访问协议，这样，一次就只有一个线程能够使用该共享数据。可见性要更加复杂一些，
它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的 ——
如果没有同步机制提供的这种可见性保证，线程看到的共享变量可能是修改前的值或不一致的值，这将引发许多严重问题。
Volatile 变量具有 synchronized 的可见性特性，但是不具备原子特性。这就是说线程能够自动发现
volatile 变量的最新值。Volatile
变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用
volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start
&=end”）。
出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile
变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile
变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile
变量还可以提供优于锁的性能优势。
您只能在有限的一些情形下使用 volatile 变量替代锁。要使 volatile 变量提供理想的线程安全，必须同时满足下面两个条件：
对变量的写操作不依赖于当前值。
该变量没有包含在具有其他变量的不变式中。
实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。
第一个条件的限制使 volatile 变量不能用作线程安全计数器。虽然增量操作（x++）看上去类似一个单独操作，实际上它是一个由读取－修改－写入操作序列组成的组合操作，必须以原子方式执行，而 volatile 不能提供必须的原子特性。实现正确的操作需要使 x 的值在操作期间保持不变，而 volatile 变量无法实现这点。（然而，如果将值调整为只从单个线程写入，那么可以忽略第一个条件。）
大多数编程情形都会与这两个条件的其中之一冲突，使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全。清单 1 显示了一个非线程安全的数值范围类。它包含了一个不变式 —— 下界总是小于或等于上界。
@NotThreadSafe
public class NumberRange {
private int lower,
public int getLower() { }
public int getUpper() { }
public void setLower(int value) {
if (value & upper)
throw new IllegalArgumentException(...);
public void setUpper(int value) {
if (value & lower)
throw new IllegalArgumentException(...);
这种方式限制了范围的状态变量，因此将 lower 和 upper 字段定义为 volatile 类型不能够充分实现类的线程安全；从而仍然需要使用同步。否则，如果凑巧两个线程在同一时间使用不一致的值执行 setLower 和 setUpper 的话，则会使范围处于不一致的状态。例如，如果初始状态是 (0, 5)，同一时间内，线程 A 调用 setLower(4) 并且线程 B 调用 setUpper(3)，显然这两个操作交叉存入的值是不符合条件的，那么两个线程都会通过用于保护不变式的检查，使得最后的范围值是 (4, 3) —— 一个无效值。至于针对范围的其他操作，我们需要使 setLower() 和 setUpper() 操作原子化 —— 而将字段定义为 volatile 类型是无法实现这一目的的。
使用 volatile 变量的主要原因是其简易性：在某些情形下，使用 volatile 变量要比使用相应的锁简单得多。使用 volatile 变量次要原因是其性能：某些情况下，volatile 变量同步机制的性能要优于锁。
很难做出准确、全面的评价，例如 “X 总是比 Y 快”，尤其是对 JVM 内在的操作而言。（例如，某些情况下 VM 也许能够完全删除锁机制，这使得我们难以抽象地比较 volatile
和 synchronized 的开销。）就是说，在目前大多数的处理器架构上，volatile 读操作开销非常低 ——
几乎和非 volatile 读操作一样。而 volatile 写操作的开销要比非 volatile
写操作多很多，因为要保证可见性需要实现内存界定（Memory Fence），即便如此，volatile 的总开销仍然要比锁获取低。
volatile 操作不会像锁一样造成阻塞，因此，在能够安全使用 volatile 的情况下，volatile 可以提供一些优于锁的可伸缩特性。如果读操作的次数要远远超过写操作，与锁相比，volatile 变量通常能够减少同步的性能开销。
很多并发性专家事实上往往引导用户远离 volatile
变量，因为使用它们要比使用锁更加容易出错。然而，如果谨慎地遵循一些良好定义的模式，就能够在很多场合内安全地使用 volatile
变量。要始终牢记使用 volatile 的限制 —— 只有在状态真正独立于程序内其他内容时才能使用 volatile ——
这条规则能够避免将这些模式扩展到不安全的用例。
也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。
很多应用程序包含了一种控制结构，形式为 “在还没有准备好停止程序时再执行一些工作”，如清单 2 所示：
volatile boolean shutdownR
public void shutdown() { shutdownRequested = }
public void doWork() {
while (!shutdownRequested) {
// do stuff
很可能会从循环外部调用
shutdown() 方法 —— 即在另一个线程中 —— 因此，需要执行某种同步来确保正确实现 shutdownRequested 变量的可见性。（可能会从 JMX 侦听程序、GUI 事件线程中的操作侦听程序、通过 RMI 、通过一个 Web 服务等调用）。然而，使用
synchronized 块编写循环要比使用清单 2 所示的 volatile 状态标志编写麻烦很多。由于
volatile 简化了编码，并且状态标志并不依赖于程序内任何其他状态，因此此处非常适合使用 volatile。
这种类型的状态标记的一个公共特性是：通常只有一种状态转换；shutdownRequested 标志从 false 转换为 true，然后程序停止。这种模式可以扩展到来回转换的状态标志，但是只有在转换周期不被察觉的情况下才能扩展（从 false 到 true，再转换到 false）。此外，还需要某些原子状态转换机制，例如原子变量。
缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原语值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线
程写入）和该对象状态的旧值同时存在。（这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有
同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象）。
实现安全发布对象的一种技术就是将对象引用定义为 volatile 类型。清单 3 展示了一个示例，其中后台线程在启动阶段从数据库加载一些数据。其他代码在能够利用这些数据时，在使用之前将检查这些数据是否曾经发布过。
public class BackgroundFloobleLoader {
public volatile Flooble theF
public void initInBackground() {
// do lots of stuff
theFlooble = new Flooble();
// this is the only write to theFlooble
public class SomeOtherClass {
public void doWork() {
while (true) {
// do some stuff...
// use the Flooble, but only if it is ready
if (floobleLoader.theFlooble != null)
doSomething(floobleLoader.theFlooble);
如果 theFlooble 引用不是 volatile 类型，doWork() 中的代码在解除对 theFlooble 的引用时，将会得到一个不完全构造的 Flooble。
该模式的一个必要条件是：被发布的对象必须是线程安全的，或者是有效的不可变对象（有效不可变意味着对象的状态在发布之后永远不会被修改）。volatile 类型的引用可以确保对象的发布形式的可见性，但是如果对象的状态在发布后将发生更改，那么就需要额外的同步。
安全使用 volatile 的另一种简单模式是：定期 “发布”
观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的
volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。
使用该模式的另一种应用程序就是收集程序的统计信息。清单 4 展示了身份验证机制如何记忆最近一次登录的用户的名字。将反复使用 lastUser 引用来发布值，以供程序的其他部分使用。
public class UserManager {
public volatile String lastU
public boolean authenticate(String user, String password) {
boolean valid = passwordIsValid(user, password);
if (valid) {
User u = new User();
activeUsers.add(u);
lastUser =
该模式是前面模式的扩展；将某个值发布以在程序内的其他地方使用，但是与一次性事件的发布不同，这是一系列独立事件。这个模式要求被发布的值是有效不可变的 —— 即值的状态在发布后不会更改。使用该值的代码需要清楚该值可能随时发生变化。
volatile bean 模式适用于将 JavaBeans 作为“荣誉结构”使用的框架。在 volatile bean
模式中，JavaBean 被用作一组具有 getter 和/或 setter 方法 的独立属性的容器。volatile bean
模式的基本原理是：很多框架为易变数据的持有者（例如 HttpSession）提供了容器，但是放入这些容器中的对象必须是线程安全的。
在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter
方法必须非常普通 ——
除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。（这将禁止具有数组值的属性，因为当数组
引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义）。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。清单 5 中的示例展示了遵守 volatile bean 模式的 JavaBean：
@ThreadSafe
public class Person {
private volatile String firstN
private volatile String lastN
public String getFirstName() { return firstN }
public String getLastName() { return lastN }
public int getAge() { }
public void setFirstName(String firstName) {
this.firstName = firstN
public void setLastName(String lastName) {
this.lastName = lastN
public void setAge(int age) {
this.age =
前面几节介绍的模式涵盖了大部分的基本用例，在这些模式中使用 volatile 非常有用并且简单。这一节将介绍一种更加高级的模式，在该模式中，volatile 将提供性能或可伸缩性优势。
应用的的高级模式非常脆弱。因此，必须对假设的条件仔细证明，并且这些模式被严格地封装了起来，因为即使非常小的更改也会损坏您的代码！同样，使用更高级
的 volatile
用例的原因是它能够提升性能，确保在开始应用高级模式之前，真正确定需要实现这种性能获益。需要对这些模式进行权衡，放弃可读性或可维护性来换取可能的性
能收益 ——
如果您不需要提升性能（或者不能够通过一个严格的测试程序证明您需要它），那么这很可能是一次糟糕的交易，因为您很可能会得不偿失，换来的东西要比放弃的
东西价值更低。
目前为止，您应该了解了 volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作（读、添加、存储）的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。
然而，如果读操作远远超过写操作，您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。清单 6 中显示的线程安全的计数器使用
synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。
@ThreadSafe
public class CheesyCounter {
// Employs the cheap read-write lock trick
// All mutative operations MUST be done with the 'this' lock held
@GuardedBy("this") private volatile
public int getValue() { }
public synchronized int increment() {
return value++;
之所以将这种技术称之为 “开销较低的读－写锁” 是因为您使用了不同的同步机制进行读写操作。因为本例中的写操作违反了使用 volatile
的第一个条件，因此不能使用 volatile 安全地实现计数器 —— 您必须使用锁。然而，您可以在读操作中使用 volatile 确保当前值的可见性，
因此可以使用锁进行所有变化的操作，使用 volatile 进行只读操作。其中，锁一次只允许一个线程访问值，volatile
允许多个线程执行读操作，因此当使用 volatile 保证读代码路径时，要比使用锁执行全部代码路径获得更高的共享度 ——
就像读－写操作一样。然而，要随时牢记这种模式的弱点：如果超越了该模式的最基本应用，结合这两个竞争的同步机制将变得非常困难。
与锁相比，Volatile 变量是一种非常简单但同时又非常脆弱的同步机制，它在某些情况下将提供优于锁的性能和伸缩性。如果严格遵循 volatile 的使用条件 —— 即变量真正独立于其他变量和自己以前的值 —— 在某些情况下可以使用 volatile 代替 synchronized 来简化代码。然而，使用 volatile 的代码往往比使用锁的代码更加容易出错。本文介绍的模式涵盖了可以使用 volatile 代替 synchronized 的最常见的一些用例。遵循这些模式（注意使用时不要超过各自的限制）可以帮助您安全地实现大多数用例，使用 volatile 变量获得更佳性能。
/developerworks/cn/java/j-jtp06197.html
temper 阅读(93) |
java调用bat，用xcopy拷贝系统日志到指定目录。如果jdk版本是32位，因为微软做了系统重定向，不能拷贝过去。
将%WinDir%\System32\Winevt\Logs\Application.evtx修改为%WinDir%\Sysnative\Winevt\Logs\Application.evtx，即可实现。
参考资料：/kb/942589/
temper 阅读(634) |
http://blog.csdn.net/watchnight/archive//5258532.aspx
没有一个平台独立的方法能够在所有的JVM上实现。一个最简单、最接近取得PID的办法是使用：
ManagementFactory.getRuntimeMXBean().getName() 。
取得到的字符窜的格式为[PROCESS_ID]@[MACHINE_NAME]，通过解析这个字符串就可以得到java进程的PID。
在以下平台上测试通过：
1、Windows、Linux上的Sun JDK1.5、JDK6
2、HP-UX上的JDK1.5、JDK6
3、Linux上的JRockit &R27.6
temper 阅读(805) |
将jvm.dll拷贝到JavaService.exe所在目录（也可以通过设置path实现）
参照：http://forge.ow2.org/forum/forum.php?thread_id=2330&forum_id=625
ps：推荐通过设置path来实现，毕竟这样对用户和空间需求改动最小。
temper 阅读(148) |
原文：http://roylone./blog/static//
一、相关概念
基本回收算法
引用计数（Reference Counting）
比较古老的回收算法。原理是此对象有一个引用，即
增加一个计数，删除一个引用则减少一个计数。垃圾回收时，只用收集计数为0的对象。此算法最致命的是无法处理循环引用的问题。
标记-清除（Mark-Sweep）
此算法执行分两阶段。第一阶段从引用根节点开始标记所
有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。此算法需要暂停整个应用，同时，会产生内存碎片。
复制（Copying）
此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃
圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进
行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。
标记-整理（Mark-Compact）
此算法结合了“标记-清除”和“复制”两个算法的
优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排
放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。
增量收集（Incremental Collecting）
实施垃圾回收算法，即：在应用
进行的同时进行垃圾回收。不知道什么原因JDK5.0中的收集器没有使用这种算法的。
分代（Generational Collecting）
基于对对象生命周期分析后得出的
垃圾回收算法。把对象分为年青代、年老代、持久代，对不同生命周期的对象使用不同的算法（上述方式中的一个）进行回收。现在的垃圾回收器（从
J2SE1.2开始）都是使用此算法的。
分代垃圾回收详述
如上图所示，为Java堆中的各代分布。
Young（年轻代）
年轻代分三个区。一个Eden区，两个Survivor区。大部分对象在
Eden区中生成。当Eden区满时，还存活的对象将被复制到Survivor区（两个中的一个），当这个Survivor区满时，此区的存活对象将被复
制到另外一个Survivor区，当这个Survivor去也满了的时候，从第一个Survivor区复制过来的并且此时还存活的对象，将被复制“年老区
(Tenured)”。需要注意，Survivor的两个区是对称的，没先后关系，所以同一个区中可能同时存在从Eden复制过来
对象，和从前一个Survivor复制过来的对象，而复制到年老区的只有从第一个Survivor去过来的对象。而且，Survivor区总有一个是空
Tenured（年老代）
年老代存放从年轻代存活的对象。一般来说年老代存放的都是生命期
较长的对象。
Perm（持久代）
用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著
影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增
的类。持久代大小通过-XX:MaxPermSize=&N&进行设置。
GC有两种类型：Scavenge GC和Full
Scavenge GC
一般情况下，当新对象生成，并且在Eden申请空间失败时，就好触发Scavenge
GC，堆Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。
对整个堆进行整理，包括Young、Tenured和Perm。Full GC比Scavenge
GC要慢，因此应该尽可能减少Full GC。有如下原因可能导致Full GC：
Tenured被写满
Perm域被写满
System.gc()被显示调用
上一次GC之后Heap的各域分配策略动态变化
分代垃圾回收过程演示
二、垃圾回收器
目前的收集器主要有三种：串行
收集器、并行收集器、并发收集器。
串行收集器
使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高。但是，也
无法使用多处理器的优势，所以此收集器适合单处理器机器。当然，此收集器也可以用在小数据量（100M左右）情况下的
多处理器机器上。可以使用-XX:+UseSerialGC打开。
并行收集器
对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用。使用-XX:+UseParallelGC.
打开。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中进行了增强--可以堆年老代进行并行收集。如果年老代不使
用并发收集的话，是使用单线程进行垃圾回收，因此会制约扩展能力。使用-XX:+UseParallelOldGC打
使用-XX:ParallelGCThreads=&N&设置并行垃圾回收的线程数。此
值可以设置与机器处理器数量相等。
此收集器可以进行如下配置：
最大垃圾回收暂停:指定垃圾回收时的最长暂停时间，通过-XX:MaxGCPauseMillis=&N&指
定。&N&为毫秒.如果指定了此值的话，堆大小和垃圾回收相关参数会进行调整以达到指定值。设定此值可能
会减少应用的吞吐量。
吞吐量:吞吐量为垃圾回收时间与非垃圾回收时间的比值，通过-XX:GCTimeRatio=&N&来
设定，公式为1/（1+N）。例如，-XX:GCTimeRatio=19时，表示5%的时间用于垃圾回收。默认情况
为99，即1%的时间用于垃圾回收。
并发收集器
可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收
集器适合对响应时间要求比较高的中、大规模应用。使用-XX:+UseConcMarkSweepGC打开。
并发收集器主要减少年老代的暂停时间，他在应用不停止的情况下使用独立的垃圾回收线程，跟踪可达对象。在每个年老代垃圾回收周期中，在收集初期并
发收集器会对整个应用进行简短的暂停，在收集中还会再暂停一次。第二次暂停会比第一次稍长，在此过程中多个线程同时进行垃圾回收工作。
并发收集器使用处理器换来短暂的停顿时间。在一个N个处理器的系统上，并发收集部分使用K/N个
可用处理器进行回收，一般情况下1&=K&=N/4。
在只有一个处理器的主机上使用并发收集器，设置为incremental
mode模式也可获得较短的停顿时间。
浮动垃圾：由于在应用运行的同时进行垃圾回收，所以有些垃圾可能在垃圾回收进行完成时产生，这样就
造成了“Floating Garbage”，这些垃圾需要在下次垃圾回收周期时才能回收掉。所以，并发收集器一般需要20%的
预留空间用于这些浮动垃圾。
Concurrent Mode Failure：并发收集器在应用运行时进行收集，所以需要保证
堆在垃圾回收的这段时间有足够的空间供程序使用，否则，垃圾回收还未完成，堆空间先满了。这种情况下将会发生“并发模式失败”，此时整个应用将会暂停，进
行垃圾回收。
启动并发收集器：因为并发收集在应用运行时进行收集，所以必须保证收集完成之前有足够的内存空间供
程序使用，否则会出现“Concurrent Mode Failure”。通过设置-XX:CMSInitiatingOccupancyFraction=&N&指
定还有多少剩余堆时开始执行并发收集
串行处理器：
&--适用情况：数据量比较小（100M左右）；单处理器下并且对响应时间无要求的应
&--缺点：只能用于小型应用
并行处理器：
&--适用情况：“对吞吐量有高要求”，多CPU、对应用响应时间无要求的
中、大型应用。举例：后台处理、科学计算。
&--缺点：应用响应时间可能较长
并发处理器：
&--适用情况：“对响应时间有高要求”，多CPU、对应用响应时间有较高要
求的中、大型应用。举例：Web服务器/应用服务器、电信交换、集成开发环境。
三、常见配置举例
堆大小设置
中最大堆大小有三方面限制：相关操作系统的数据模型（32-bt还是64-bit）限制；系统的可用虚拟内存限制；系统的可用物理内存限制。32位系统
下，一般限制在1.5G~2G；64为操作系统对内存无限制。我在Windows Server 2003
系统，3.5G物理内存，JDK5.0下测试，最大可设置为1478m。
典型设置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-Xmx3550m：
设置JVM最大可用内存为3550M。
-Xms3550m：
设置JVM促使内存为3550m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-Xmn2g：设置年轻代大小为2G。整个堆大小=年轻代大小 + 年老代大小 + 持久代大小。持久代一般固定大小为
64m，所以增大年轻代后，将会减小年老代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8。
-Xss128k：
设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内
存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在左右。
java -Xmx3550m -Xms3550m -Xss128k
-XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m
-XX:MaxTenuringThreshold=0
-XX:NewRatio=4:
设置年轻代（包括Eden和两个Survivor区）与年老代的比值（除去持久代）。设置为4，则年轻代与年老代所占比值为1：4，年轻代占整个堆栈的
-XX:SurvivorRatio=4：设置年轻代中
Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的
-XX:MaxPermSize=16m:设置持久代大小为16m。
-XX:MaxTenuringThreshold=0：
设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年
老代。对于年老代比较多的应用，可以提高效率。如果将此
值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年
轻代即被回收的概论。
回收器选择
JVM给了三种选择：串行收集器、并行收集器、并发收集器，
但是串行收集器只适用于小数据量的情况，所以这里的选择主要针对并行收集器和并发收集器。默认情况下，JDK5.0以前都是使用串行收集器，如果想使用其
他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前进行判断。
吞吐量优先的并行收集器
如上文所述，并行收集器主要以到达一定的吞吐量为目标，适用于科学技术和后台
典型配置：
java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC
-XX:ParallelGCThreads=20
-XX:+UseParallelGC：
选择垃圾收集器为并行收集器。此配置仅对年轻代有效。即上述配置下，年轻代使用并发收集，
而年老代仍旧使用串行收集。
-XX:ParallelGCThreads=20：
配置并行收集器的线程数，即：同时多少个线程一起进行垃圾回收。此值最好配置与处理器数目相等。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：
配置年老代垃圾收集方式为并行收集。JDK6.0支持对年老代并行收集。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:+UseParallelGC& -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:设
置每次年轻代垃圾回收的最长时间，如果无法满足此时间，JVM会自动调整年轻代大小，以满足此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:+UseParallelGC& -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：
设置此选项后，并行收集器会自动选择年轻代区大小和相应的Survivor区比例，以达到目标系统规定的最低相应时间或者收集频率等，此值建议使用并行收
集器时，一直打开。
响应时间优先的并发收集器
如上文所述，并发收集器主要是保证系统的响应时间，减少垃圾收集
时的停顿时间。适用于应用服务器、电信领域等。
典型配置：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：
设置年老代为并发收集。测试中配置这个以后，-XX:NewRatio=4的配置失效了，原因不明。所以，此时年轻代大小最好
用-Xmn设置。
-XX:+UseParNewGC:设
置年轻代为并行收集。可与CMS收集同时使用。JDK5.0以上，JVM会根据系统配置自行设置，所以无需再设置此值。
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
-XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：
由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整
-XX:+UseCMSCompactAtFullCollection：打开对年
老代的压缩。可能会影响性能，但是可以消除碎片
JVM提供了大量命令行参数，打印信息，供调试使用。主要有以下一些：
-XX:+PrintGC
输出形式：[GC
118250K-&0112K), 0.0094143 secs]
&&&&&&&&&&&&&&& [Full GC 121376K-&1K),
0.0650971 secs]
-XX:+PrintGCDetails
输出形式：[GC
[DefNew: 8614K-&781K(9088K), 0.0123035 secs]
118250K-&0112K), 0.0124633 secs]
&&&&&&&&&&&&&&& [GC [DefNew: 8614K-&K),
0.0000665 secs][Tenured: 112761K-&1K), 0.0433488 secs]
121376K-&1K), 0.0436268 secs]
-XX:+PrintGCTimeStamps
-XX:+PrintGC：PrintGCTimeStamps可与上面两个混合使用
输出形式：11.851: [GC
98328K-&9K), 0.0082960 secs]
-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收
前，程序未中断的执行时间。可与上面混合使用
输出形式：Application time: 0.5291524
-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂
停的时间。可与上面混合使用
输出形式：Total time for which application threads
were stopped: 0.0468229 seconds
-XX:PrintHeapAtGC:打印GC前后的详细堆栈信息
输出形式：
[GC {Heap before gc invocations=7:
&def new generation&& total
55296K, used 52568K [0x1ebddd0000)
space 49152K,& 99% used [0x1ebdbce430, 0x21bd0000)
space 6144K,& 55% used [0x221d27e10, 0x227d0000)
to&& space 6144K,&& 0% used [0x21bdbdd0000)
generation&& total 69632K, used 2696K [0x227dbd0000,
0x26bd0000)
the space 69632K,&& 3% used [0x227d0000,
0x22a720f8, 0x22a7bd0000)
&compacting perm gen& total
8192K, used 2898K [0x26bddabd0000)
&& the space
8192K,& 35% used [0x26bdea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K,& 66% used [0x2abdb12bcc0, 0x2b12be00,
0x2b3d0000)
&&& rw space 12288K,& 46% used [0x2b3db972060,
0x2bx2bfd0000)
34.735: [DefNew: 52568K-&K),
0.0072126 secs] 55264K-&K)Heap after gc
invocations=8:
&def new generation&& total 55296K, used
3433K [0x1ebddd0000)
eden space
49152K,&& 0% used [0x1ebdebdbd0000)
from space 6144K,& 55% used [0x21bdf2a5e8, 0x221d0000)
to&& space 6144K,&& 0% used [0x221ddd0000)
generation&& total 69632K, used 3182K [0x227dbd0000,
0x26bd0000)
the space 69632K,&& 4% used [0x227d0000,
0x22aeb958, 0x22aeba00, 0x26bd0000)
&compacting perm gen& total
8192K, used 2898K [0x26bddabd0000)
&& the space
8192K,& 35% used [0x26bdea4ba8, 0x26ea4c00, 0x273d0000)
ro space 8192K,& 66% used [0x2abdb12bcc0, 0x2b12be00,
0x2b3d0000)
&&& rw space 12288K,& 46% used [0x2b3db972060,
0x2bx2bfd0000)
, 0.0757599 secs]
-Xloggc:filename:与上面几个配合使用，把相关日志信息记录到文件以便分析。
常见配置汇总
-Xms:初始堆大小
-Xmx:最大堆大小
-XX:NewSize=n:设置年轻代大小
-XX:NewRatio=n:设置年轻代和年老代的比值。如:为3，表示年轻代与年老代比值为
1：3，年轻代占整个年轻代年老代和的1/4
-XX:SurvivorRatio=n:年轻代中Eden区与两个Survivor区的比值。注
意Survivor区有两个。如：3，表示Eden：Survivor=3：2，一个Survivor区占整个年轻代的1/5
-XX:MaxPermSize=n:设置持久代大小
收集器设置
-XX:+UseSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置并行年老代收集器
-XX:+UseConcMarkSweepGC:设置并发收集器
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
并行收集器设置
-XX:ParallelGCThreads=n:设置并行收集器收集时使用的CPU数。并行收集线程数。
-XX:MaxGCPauseMillis=n:设置并行收集最大暂停时间
-XX:GCTimeRatio=n:设置垃圾回收时间占程序运行时间的百分比。公式为
并发收集器设置
-XX:+CMSIncrementalMode:设置为增量模式。适用于单CPU情况。
-XX:ParallelGCThreads=n:设置并发收集器年轻代收集方式为并行收集时，使
用的CPU数。并行收集线程数。
年轻代大小选择
响应时间优先的应用：尽可能设大，直到接近系
统的最低响应时间限制（根据实际情况选择）。在此种情况下，年轻代收集发生的频率也是最小的。同时，减少到达年老代的对
吞吐量优先的应用：尽可能的设置大，可能到达Gbit的程度。因为对响应时间没有要求，垃圾收集可
以并行进行，一般适合8CPU以上的应用。
年老代大小选择
响应时间优先的应用：年老代使用并发收集器，所以其大小需要小心设置，一般要考虑并发会话率和会
话持续时间等一些参数。如果堆设置小了，可以会造成内存碎片、高回收频率以及应用暂停而使用传统的标记清除方式；如果堆大了，则需要较
长的收集时间。最优化的方案，一般需要参考以下数据获得：
并发垃圾收集信息
持久代并发收集次数
传统GC信息
花在年轻代和年老代回收上的时间比例
减少年轻代和年老代花费的时间，一般会提高应用的效率
吞吐量优先的应用：一般吞吐量优先的应用都有一个很大的年轻代和一个较小的年老代。原因是，这样可
以尽可能回收掉大部分短期对象，减少中期的对象，而年老代尽存放长期存活对象。
较小堆引起的碎片问题
因为年老代的并发收集器使用标记、清除算法，所以不会对堆进行压缩。
当收集器回收时，他会把相邻的空间进行合并，这样可以分配给较大的对象。但是，当堆空间较小时，运行一段时间以后，就会出现“碎片”，如果并发收集器找不
到足够的空间，那么并发收集器将会停止，然后使用传统的标记、清除方式进行回收。如果出现“碎片”，可能需要进行如下配置：
-XX:+UseCMSCompactAtFullCollection：使用并发收集器时，开启对年老代的压缩。
-XX:CMSFullGCsBeforeCompaction=0：上面配置开启的情况下，这里设置多少次Full
GC后，对年老代进行压缩
temper 阅读(85) |