亚洲美女视频网站,亚洲依依成人精品,亚洲熟妇无码另类久久久

2009年5月8日

win7自動升級到了ie11，但是debug工具太難用了，準備會退到9，但是在添加刪除程序里，把ie11的功能關閉，安裝9時，提示ie已經安裝。
并且ie圖標也沒了。。progrem files下面的ie啟動程序也沒了。。。。

最好在這找到了卸載的辦法
http://www.iefans.net/windows-7-ie11-wufa-xiezai-chongxin-anzhuang-gengxin-banben/

posted @ 2014-02-10 18:43 temper 閱讀(4214) | 評論 (1) | 編輯收藏

struts2-dojo-plugin jar包存在問題

工作中用到了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,問題解決

posted @ 2013-11-20 17:10 temper 閱讀(2630) | 評論 (2) | 編輯收藏

jvm option的一點mark

JVM的-XX:[+/-]<option>以前竟然沒注意，mark一個：Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>. http://t.cn/qkcrs

posted @ 2012-12-10 10:47 temper 閱讀(331) | 評論 (0) | 編輯收藏

weblogic真坑爹

昨天配了兩個weblogic節點，但是怎么也啟動不起來。以前這種操作做了十幾次了，沒遇到過這種問題。
錯誤如下：

weblogic.security.SecurityInitializationException: 認証が拒否されました。起動アイデンティティが有効ではありません。起動アイデンティティ?ファイル(boot.properties)のユーザー名またはパスワード(もしくはその雙方)が有効ではありません。起動アイデンティティ?ファイルが作成された後に起動アイデンティティが変更されていることが考えられます。適切な値のユーザー名およびパスワードで起動アイデンティティ?ファイルを編集および更新してください。更新された起動アイデンティティ?ファイルを使用して初めてサーバーを起動するときには、それらの値は暗號化されます。
   at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.doBootAuthorization(CommonSecurityServiceManagerDelegateImpl.java:960)
   at weblogic.security.service.CommonSecurityServiceManagerDelegateImpl.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 com.bea.common.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比啥都強，實在不明白這么做得原因是啥。

不過以后搭建環境時，一定要先把系統要修改的做完，然后再裝其他軟件。

posted @ 2012-01-31 11:25 temper 閱讀(2874) | 評論 (0) | 編輯收藏

HP-UX下使用64位JDK

在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參數即可。

轉載自

posted @ 2011-09-27 14:44 temper 閱讀(1585) | 評論 (0) | 編輯收藏

window下jni調用dll和linux下jni調用so庫(轉)

最近的項目涉及到了JAVA需要調用C程序的問題。主要是調用C寫的加密算法。
主要解決方案是應用JNI去調用C生成的so庫
用eclispe新建一個java project項目,項目名稱為spidHandle，注意下面VC的項目名稱也是spidHandle，他們分別是用eclispe和VC6.0創建的，不是同個項目。
編寫一個JNI入口類SpidHandle.java：

Java代碼

package com.spidHandle.api;
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 Library;工程名命名為spidhandle;點擊確定。
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=icpid;
*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_key;
*p=strlen(md5);
p++;
strcpy(p,md5);
p+=strlen(md5);
MD5 m1;
m1 << md5 << login_user << login_pwd;
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=2431036272
#
# 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:
#   http://java.sun.com/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=0x00000000

Registers:
EAX=0x00000000, EBX=0xb71dd7c0, ECX=0xb71f87e0, EDX=0x00000ffc
ESP=0x90e696d4, EBP=0x90e69748, ESI=0x0825b0a8, EDI=0x00090e69
EIP=0xb6e5a1ef, CR2=0x00000000, EFLAGS=0x00010296

Top of Stack: (sp=0x90e696d4)
0x90e696d4:   b71d5ec8 00000000 b6e5a127 b7783a30
0x90e696e4:   b77624c0 00000000 90e69700 0825b0a8
0x90e696f4:   080de058 080de060 080de44c 085bbc00
0x90e69704:   00000000 b77d8ff4 9106c730 085bbc00
0x90e69714:   90e69750 b77c7f56 9106c8e8 085bbc00
0x90e69724:   00000001 00000005 00000000 90dd6601
0x90e69734:   90dd6000 00004044 90dd9ff4 927ec5f4
0x90e69744:   085bbc00 90e69768 90dd6fbd 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/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;+0
j com.spidHandle.api.SpidHandle.buildSpID(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;+6
j com.play.servlet.PlayServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+1044
j org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+376
j org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+101
j org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+804
j org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+365
j org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+64
j org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+6
j org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+42
j org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V+158
j org.apache.coyote.http11.Http11Processor.process(Ljava/net/Socket;)V+514
j org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ljava/net/Socket;)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/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;+0
j com.spidHandle.api.SpidHandle.buildSpID(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;+6
j com.play.servlet.PlayServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+1044
j org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+376
j org.apache.catalina.core.ApplicationFilterChain.doFilter(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+101
j org.apache.catalina.core.StandardWrapperValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+804
j org.apache.catalina.core.StandardContextValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+365
j org.apache.catalina.core.StandardHostValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+64
j org.apache.catalina.valves.ErrorReportValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+6
j org.apache.catalina.core.StandardEngineValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+42
j org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V+158
j org.apache.coyote.http11.Http11Processor.process(Ljava/net/Socket;)V+514
j org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ljava/net/Socket;)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)]
0x9105f400 JavaThread "TP-Processor3" daemon [_thread_blocked, id=23617, stack(0x90f0d000,0x90f5e000)]
0x9102f800 JavaThread "TP-Processor2" daemon [_thread_blocked, id=23616, stack(0x90f5e000,0x90faf000)]
0x912ea400 JavaThread "TP-Processor1" daemon [_thread_blocked, id=23615, stack(0x90faf000,0x91000000)]
0x912da000 JavaThread "http-8080-Acceptor-0" daemon [_thread_in_native, id=23614, stack(0x9113c000,0x9118d000)]
0x91036000 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=23613, stack(0x9118d000,0x911de000)]
0x912ac400 JavaThread "GC Daemon" daemon [_thread_blocked, id=23612, stack(0x91305000,0x91356000)]
0x91615c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=23610, stack(0x9141d000,0x9146e000)]
0x91613c00 JavaThread "CompilerThread1" daemon [_thread_blocked, id=23609, stack(0x9146e000,0x914ef000)]
0x91612000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=23608, stack(0x914ef000,0x91570000)]
0x91610800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=23607, stack(0x91570000,0x915c1000)]
0x91600800 JavaThread "Finalizer" daemon [_thread_blocked, id=23606, stack(0x9170f000,0x91760000)]
0x080d8400 JavaThread "Reference Handler" daemon [_thread_blocked, id=23605, stack(0x91760000,0x917b1000)]
0x08058400 JavaThread "main" [_thread_in_native, id=23601, stack(0xb6a4e000,0xb6a9f000)]

Other Threads:
0x080d4400 VMThread [stack: 0x917b1000,0x91832000] [id=23604]
0x91617800 WatcherThread [stack: 0x9139c000,0x9141d000] [id=23611]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
PSYoungGen      total 24448K, used 339K [0xb0420000, 0xb1da0000, 0xb3900000)
eden space 23168K, 1% used [0xb0420000,0xb0474cf8,0xb1ac0000)
from space 1280K, 0% used [0xb1c20000,0xb1c20000,0xb1d60000)
to   space 1408K, 0% used [0xb1ac0000,0xb1ac0000,0xb1c20000)
PSOldGen        total 27072K, used 8597K [0x95d00000, 0x97770000, 0xb0420000)
object space 27072K, 31% used [0x95d00000,0x96565510,0x97770000)
PSPermGen       total 19200K, used 11186K [0x91d00000, 0x92fc0000, 0x95d00000)
object space 19200K, 58% used [0x91d00000,0x927ec980,0x92fc0000)

Dynamic libraries:
08048000-08052000 r-xp 00000000 08:03 5775425    /usr/java/jdk1.6.0_16/bin/java
08052000-08053000 rwxp 00009000 08:03 5775425    /usr/java/jdk1.6.0_16/bin/java
08053000-08c64000 rwxp 00000000 00:00 0          [heap]
90cac000-90cb9000 r-xp 00000000 08:03 28295296   /lib/libgcc_s.so.1
90cb9000-90cba000 r-xp 0000c000 08:03 28295296   /lib/libgcc_s.so.1
90cba000-90cbb000 rwxp 0000d000 08:03 28295296   /lib/libgcc_s.so.1
90cbb000-90da3000 r-xp 00000000 08:03 5337022    /usr/lib/libstdc++.so.6.0.10
90da3000-90da7000 r-xp 000e7000 08:03 5337022    /usr/lib/libstdc++.so.6.0.10
90da7000-90da8000 rwxp 000eb000 08:03 5337022    /usr/lib/libstdc++.so.6.0.10
90da8000-90dae000 rwxp 00000000 00:00 0
90dd6000-90dd9000 r-xp 00000000 08:03 27729947   /home/play/lib/libspidhandle.so
90dd9000-90dda000 r-xp 00002000 08:03 27729947   /home/play/lib/libspidhandle.so
90dda000-90ddb000 rwxp 00003000 08:03 27729947   /home/play/lib/libspidhandle.so
90ddb000-90ddc000 r-xs 0000e000 08:03 5808917    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/spidhandle.jar
90ddc000-90ddd000 r-xs 00001000 08:03 5808916    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/slf4j-simple-1.5.8.jar
90ddd000-90ddf000 r-xs 00004000 08:03 5808915    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/slf4j-api-1.5.6.jar
90ddf000-90de5000 r-xs 00035000 08:03 5808914    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/logback-core-0.9.15.jar
90de5000-90dea000 r-xs 00023000 08:03 5808913    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/logback-classic-0.9.15.jar
90dea000-90df1000 r-xs 00059000 08:03 5808912    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/log4j-1.2.15.jar
90df1000-90dfd000 r-xs 000a2000 08:03 5808911    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jxl.jar
90dfd000-90e07000 r-xs 0005c000 08:03 5808910    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jstl-1.2.jar
90e07000-90e1a000 r-xs 00114000 08:03 5808909    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jsf-impl.jar
90e1a000-90e1d000 ---p 00000000 00:00 0
90e1d000-90e6b000 rwxp 00000000 00:00 0          [threadstack:0004d494]
90e6b000-90e6e000 ---p 00000000 00:00 0
90e6e000-90ebc000 rwxp 00000000 00:00 0
90ebc000-90ebf000 ---p 00000000 00:00 0
90ebf000-90f0d000 rwxp 00000000 00:00 0
90f0d000-90f10000 ---p 00000000 00:00 0
90f10000-90f5e000 rwxp 00000000 00:00 0
90f5e000-90f61000 ---p 00000000 00:00 0
90f61000-90faf000 rwxp 00000000 00:00 0
90faf000-90fb2000 ---p 00000000 00:00 0
90fb2000-91000000 rwxp 00000000 00:00 0
91000000-910b3000 rwxp 00000000 00:00 0
910b3000-91100000 ---p 00000000 00:00 0
91100000-91105000 r-xs 0004a000 08:03 5808908    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/jsf-api.jar
91105000-91107000 r-xs 0000d000 08:03 5808907    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/commons-logging-1.1.1.jar
91107000-9113c000 r-xs 00000000 08:03 20439789   /var/run/nscd/dbl5FOXp (deleted)
9113c000-9113f000 ---p 00000000 00:00 0
9113f000-9118d000 rwxp 00000000 00:00 0
9118d000-91190000 ---p 00000000 00:00 0
91190000-911de000 rwxp 00000000 00:00 0
911de000-911f1000 r-xp 00000000 08:03 5784005    /usr/java/jdk1.6.0_16/jre/lib/i386/libnet.so
911f1000-911f2000 rwxp 00013000 08:03 5784005    /usr/java/jdk1.6.0_16/jre/lib/i386/libnet.so
911f2000-911f5000 r-xs 00027000 08:03 5783936    /usr/java/jdk1.6.0_16/jre/lib/ext/sunjce_provider.jar
911f5000-911fc000 r-xs 00091000 08:03 5784036    /usr/java/jdk1.6.0_16/jre/lib/jsse.jar
911fc000-91200000 r-xs 00035000 08:03 5783937    /usr/java/jdk1.6.0_16/jre/lib/ext/sunpkcs11.jar
91200000-912f8000 rwxp 00000000 00:00 0
912f8000-91300000 ---p 00000000 00:00 0
91300000-91302000 r-xs 0000a000 08:03 5808906    /usr/apache-tomcat-6.0.32/webapps/play/WEB-INF/lib/commons-codec-1.3.jar
91302000-91305000 r-xs 00013000 08:03 5784024    /usr/java/jdk1.6.0_16/jre/lib/jce.jar
91305000-91308000 ---p 00000000 00:00 0
91308000-91356000 rwxp 00000000 00:00 0
91356000-91359000 r-xs 000cb000 08:03 5783821    /usr/java/jdk1.6.0_16/jre/lib/ext/localedata.jar
91359000-9135d000 r-xs 00036000 08:03 5808320    /usr/apache-tomcat-6.0.32/lib/catalina-tribes.jar
9135d000-91360000 r-xs 0000f000 08:03 5808331    /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-es.jar
91360000-9136a000 r-xs 000b1000 08:03 5808329    /usr/apache-tomcat-6.0.32/lib/tomcat-coyote.jar
9136a000-91371000 r-xs 0007a000 08:03 5808325    /usr/apache-tomcat-6.0.32/lib/jasper.jar
91371000-91380000 r-xs 0011a000 08:03 5808321    /usr/apache-tomcat-6.0.32/lib/catalina.jar
91380000-91382000 r-xs 0001e000 08:03 5808319    /usr/apache-tomcat-6.0.32/lib/catalina-ha.jar
91382000-91386000 r-xs 0003a000 08:03 5808330    /usr/apache-tomcat-6.0.32/lib/tomcat-dbcp.jar
91386000-91388000 r-xs 0000c000 08:03 5808318    /usr/apache-tomcat-6.0.32/lib/catalina-ant.jar
91388000-9138a000 r-xs 00007000 08:03 5808323    /usr/apache-tomcat-6.0.32/lib/el-api.jar
9138a000-9138c000 r-xs 00014000 08:03 5808328    /usr/apache-tomcat-6.0.32/lib/servlet-api.jar
9138c000-9139a000 r-xs 00170000 08:03 5808322    /usr/apache-tomcat-6.0.32/lib/ecj-3.3.1.jar
9139a000-9139c000 r-xs 0000c000 08:03 5808333    /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-ja.jar
9139c000-9139d000 ---p 00000000 00:00 0
9139d000-9141d000 rwxp 00000000 00:00 0
9141d000-91420000 ---p 00000000 00:00 0
91420000-9146e000 rwxp 00000000 00:00 0
9146e000-91471000 ---p 00000000 00:00 0
91471000-914ef000 rwxp 00000000 00:00 0
914ef000-914f2000 ---p 00000000 00:00 0
914f2000-91570000 rwxp 00000000 00:00 0
91570000-91573000 ---p 00000000 00:00 0
91573000-915c1000 rwxp 00000000 00:00 0
915c1000-91600000 r-xp 00000000 08:03 5546089    /usr/lib/locale/en_US.utf8/LC_CTYPE
91600000-916ff000 rwxp 00000000 00:00 0
916ff000-91700000 ---p 00000000 00:00 0
91700000-91701000 rwxp 00000000 00:00 0
91701000-91703000 r-xs 00011000 08:03 5808326    /usr/apache-tomcat-6.0.32/lib/jsp-api.jar
91703000-91705000 r-xs 0000b000 08:03 5808332    /usr/apache-tomcat-6.0.32/lib/tomcat-i18n-fr.jar
91705000-91708000 r-xs 00019000 08:03 5808324    /usr/apache-tomcat-6.0.32/lib/jasper-el.jar
91708000-9170e000 r-xp 00000000 08:03 5784001    /usr/java/jdk1.6.0_16/jre/lib/i386/libmanagement.so
9170e000-9170f000 rwxp 00005000 08:03 5784001    /usr/java/jdk1.6.0_16/jre/lib/i386/libmanagement.so
9170f000-91712000 ---p 00000000 00:00 0
91712000-91760000 rwxp 00000000 00:00 0
91760000-91763000 ---p 00000000 00:00 0
91763000-917b1000 rwxp 00000000 00:00 0
917b1000-917b2000 ---p 00000000 00:00 0
917b2000-91865000 rwxp 00000000 00:00 0
91865000-919fb000 r-xs 02fb3000 08:03 5784038    /usr/java/jdk1.6.0_16/jre/lib/rt.jar
919fb000-919fc000 ---p 00000000 00:00 0
919fc000-91a7c000 rwxp 00000000 00:00 0
91a7c000-91a7d000 ---p 00000000 00:00 0
91a7d000-91b07000 rwxp 00000000 00:00 0
91b07000-91b1d000 rwxp 00000000 00:00 0
91b1d000-91b2b000 rwxp 00000000 00:00 0
91b2b000-91bf1000 rwxp 00000000 00:00 0
91bf1000-91bfb000 rwxp 00000000 00:00 0
91bfb000-91c11000 rwxp 00000000 00:00 0
91c11000-91c1f000 rwxp 00000000 00:00 0
91c1f000-91ce4000 rwxp 00000000 00:00 0
91ce4000-91cf2000 rwxp 00000000 00:00 0
91cf2000-91cff000 rwxp 00000000 00:00 0
91cff000-92fc0000 rwxp 00000000 00:00 0
92fc0000-95d00000 rwxp 00000000 00:00 0
95d00000-97770000 rwxp 00000000 00:00 0
97770000-b0420000 rwxp 00000000 00:00 0
b0420000-b1da0000 rwxp 00000000 00:00 0
b1da0000-b3900000 rwxp 00000000 00:00 0
b3900000-b3901000 r-xs 00003000 08:03 5808317    /usr/apache-tomcat-6.0.32/lib/annotations-api.jar
b3901000-b3902000 r-xs 00006000 08:03 5808298    /usr/apache-tomcat-6.0.32/bin/tomcat-juli.jar
b3902000-b3903000 r-xs 00005000 08:03 5808288    /usr/apache-tomcat-6.0.32/bin/commons-daemon.jar
b3903000-b390a000 r-xs 00000000 08:03 5523095    /usr/lib/gconv/gconv-modules.cache
b390a000-b3913000 rwxp 00000000 00:00 0
b3913000-b39ca000 rwxp 00000000 00:00 0
b39ca000-b3c0a000 rwxp 00000000 00:00 0
b3c0a000-b69ca000 rwxp 00000000 00:00 0
b69ca000-b69d9000 r-xp 00000000 08:03 5784014    /usr/java/jdk1.6.0_16/jre/lib/i386/libzip.so
b69d9000-b69db000 rwxp 0000e000 08:03 5784014    /usr/java/jdk1.6.0_16/jre/lib/i386/libzip.so
b69db000-b69e3000 rwxs 00000000 08:03 6743707    /tmp/hsperfdata_root/23600
b69e3000-b6a18000 r-xs 00000000 08:03 20439787   /var/run/nscd/passwd
b6a18000-b6a1e000 r-xp 00000000 08:03 5784018    /usr/java/jdk1.6.0_16/jre/lib/i386/native_threads/libhpi.so
b6a1e000-b6a1f000 rwxp 00006000 08:03 5784018    /usr/java/jdk1.6.0_16/jre/lib/i386/native_threads/libhpi.so
b6a1f000-b6a42000 r-xp 00000000 08:03 5783990    /usr/java/jdk1.6.0_16/jre/lib/i386/libjava.so
b6a42000-b6a44000 rwxp 00023000 08:03 5783990    /usr/java/jdk1.6.0_16/jre/lib/i386/libjava.so
b6a44000-b6a4c000 r-xp 00000000 08:03 28295217   /lib/librt-2.11.1.so
b6a4c000-b6a4d000 r-xp 00007000 08:03 28295217   /lib/librt-2.11.1.so
b6a4d000-b6a4e000 rwxp 00008000 08:03 28295217   /lib/librt-2.11.1.so
b6a4e000-b6a51000 ---p 00000000 00:00 0
b6a51000-b6a9f000 rwxp 00000000 00:00 0
b6a9f000-b6ac5000 r-xp 00000000 08:03 28295195   /lib/libm-2.11.1.so
b6ac5000-b6ac6000 r-xp 00026000 08:03 28295195   /lib/libm-2.11.1.so
b6ac6000-b6ac7000 rwxp 00027000 08:03 28295195   /lib/libm-2.11.1.so
b6ac7000-b7194000 r-xp 00000000 08:03 5784022    /usr/java/jdk1.6.0_16/jre/lib/i386/server/libjvm.so
b7194000-b71e2000 rwxp 006cc000 08:03 5784022    /usr/java/jdk1.6.0_16/jre/lib/i386/server/libjvm.so
b71e2000-b7605000 rwxp 00000000 00:00 0
b7605000-b7760000 r-xp 00000000 08:03 28295187   /lib/libc-2.11.1.so
b7760000-b7762000 r-xp 0015b000 08:03 28295187   /lib/libc-2.11.1.so
b7762000-b7763000 rwxp 0015d000 08:03 28295187   /lib/libc-2.11.1.so
b7763000-b7767000 rwxp 00000000 00:00 0
b7767000-b776a000 r-xp 00000000 08:03 28295193   /lib/libdl-2.11.1.so
b776a000-b776b000 r-xp 00002000 08:03 28295193   /lib/libdl-2.11.1.so
b776b000-b776c000 rwxp 00003000 08:03 28295193   /lib/libdl-2.11.1.so
b776c000-b7773000 r-xp 00000000 08:03 5783973    /usr/java/jdk1.6.0_16/jre/lib/i386/jli/libjli.so
b7773000-b7775000 rwxp 00006000 08:03 5783973    /usr/java/jdk1.6.0_16/jre/lib/i386/jli/libjli.so
b7775000-b778c000 r-xp 00000000 08:03 28295213   /lib/libpthread-2.11.1.so
b778c000-b778d000 r-xp 00016000 08:03 28295213   /lib/libpthread-2.11.1.so
b778d000-b778e000 rwxp 00017000 08:03 28295213   /lib/libpthread-2.11.1.so
b778e000-b7790000 rwxp 00000000 00:00 0
b7790000-b7791000 r-xs 00005000 08:03 5808283    /usr/apache-tomcat-6.0.32/bin/bootstrap.jar
b7791000-b7792000 rwxp 00000000 00:00 0
b7792000-b7793000 r-xp 00000000 00:00 0
b7793000-b77a8000 r-xp 00000000 08:03 28295198   /lib/libnsl-2.11.1.so
b77a8000-b77a9000 r-xp 00014000 08:03 28295198   /lib/libnsl-2.11.1.so
b77a9000-b77aa000 rwxp 00015000 08:03 28295198   /lib/libnsl-2.11.1.so
b77aa000-b77ac000 rwxp 00000000 00:00 0
b77ac000-b77b7000 r-xp 00000000 08:03 5784013    /usr/java/jdk1.6.0_16/jre/lib/i386/libverify.so
b77b7000-b77b8000 rwxp 0000b000 08:03 5784013    /usr/java/jdk1.6.0_16/jre/lib/i386/libverify.so
b77b8000-b77b9000 rwxp 00000000 00:00 0
b77b9000-b77d8000 r-xp 00000000 08:03 28295180   /lib/ld-2.11.1.so
b77d8000-b77d9000 r-xp 0001e000 08:03 28295180   /lib/ld-2.11.1.so
b77d9000-b77da000 rwxp 0001f000 08:03 28295180   /lib/ld-2.11.1.so
bfcc6000-bfcdb000 rwxp 00000000 00:00 0          [stack]
ffffe000-fffff000 r-xp 00000000 00: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=0x10000004
SIGBUS: [libjvm.so+0x650710], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGFPE: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGPIPE: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGXFSZ: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libjvm.so+0x52f600], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x5321f0], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGINT: SIG_IGN, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGTERM: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGQUIT: [libjvm.so+0x531f20], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004

--------------- 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 2010-05-20 11:14:20 +0200 i686
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 1941704k(213752k free), swap 2048276k(1540564k free)

vm_info: Java HotSpot(TM) Server VM (14.2-b01) for linux-x86 JRE (1.6.0_16-b01), built on Jul 31 2009 06:03: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 [0xb0420000, 0xb1da0000, 0xb3900000)
eden space 23168K, 1% used [0xb0420000,0xb0474cf8,0xb1ac0000)
from space 1280K, 0% used [0xb1c20000,0xb1c20000,0xb1d60000)
to space 1408K, 0% used [0xb1ac0000,0xb1ac0000,0xb1c20000)
PSOldGen total 27072K, used 8597K [0x95d00000, 0x97770000, 0xb0420000)
object space 27072K, 31% used [0x95d00000,0x96565510,0x97770000)
PSPermGen total 19200K, used 11186K [0x91d00000, 0x92fc0000, 0x95d00000)
object space 19200K, 58% used [0x91d00000,0x927ec980,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崩潰.

http://zhxmyself.iteye.com/blog/961249

posted @ 2011-09-27 14:42 temper 閱讀(6195) | 評論 (0) | 編輯收藏

signer information does not match signer informati on of other classes in the same package問題

今天客戶發過來一個新的jar包B.jar，讓我替換原來的進行測試，但是替換完畢執行后，出現如下錯誤：

C:\Program Files\Java\jdk1.5.0_16
Exception 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:12
4)
        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,也在查資料尋找出現此問題的原因，未完待續。

posted @ 2011-08-18 18:53 temper 閱讀(5112) | 評論 (0) | 編輯收藏

【轉】ExitProcess與TerminateProcess

進程只是提供了一段地址空間和內核對象，其運行時通過其他地址空間內的主線程來體現的。當主線程的進入點函數返回時，進程也就隨之而技術。這種進程的種植方式是進程的正常退出。進程中的所有縣城資源都能夠得到正確的清除。除了這種進程的正常退出方式之外，優勢還需要在程序中通過代碼來強制結束本進程或其他進程的運行。

ExitProcess

void ExitProcess(UINT uExitCode);

其參數uExitCode為進城設置了退出代碼。該函數具有強制性，在執行完畢后進程即被結束，因此位于其后的任何代碼將不能被執行。雖然 ExitProcess()函數可以再結束進程同時通知與其關聯的動態鏈接庫，但是由于他的這種強制性，使得ExitProcess()函數在使用上將存有安全隱患。例如，如果最親愛程序調用ExitProcess()函數之前曾用new操作，申請一段空間，那么敬愛那個會由于ExitProcess() 函數的強制性而無法通過delete操作符將其釋放，從而造成內存泄露。

有鑒于ExitProcess()函數的強制性和安全性，在使用時一定要引起注意。

Terminateprocess()

ExitProcess 只能強制本進程的推出，如果要在一個進程中強制結束其他的進程就需要用TerminateProcess()來實現，與ExitProcess()不同，TerminateProcess()函數執行后，被終止的進程不會得到任何關于程序退出的通知。也就是說，被終止的進程是無法再結束運行前進程推出前的收尾工作的。所以，通常只有在其他任何地方都無法迫使進程退出時才會考慮使用TerminateProcess()去強制結束進程。

BOOL TerminateProcess(HANDLE hProcess, UINT uExitCode);

參數hProcess和uExitCode分別為進城句柄和退出代碼。如果被結束的是本進程，可以通過GetCurrentProcess()獲取到句柄。 TerminateProcess()是異步執行的，在調用后返回并不能確定被終止進程是否已經真的退出，如果調用TerminateProcess() 的進程對此細節關心，可以通過WaitForSingleObject()來等待進程的真正結束。

在VC中如何結束系統正在運行的其他進程（該進程必須有窗口界面），其實很簡單，按照如下步驟進程：

1）取得進程的句柄（利用FindWindow函數得到）；

2）獲取進程ID號（用GetWindowThreadProcessId函數獲取）；

3）打開進程，OpenProcess函數中的第一個參數設為PROCESS_TERMINATE，就可以獲取處理該進程的句柄；

4）利用TerminateProcess函數結束進程，將該函數的第二個參數設為4.

posted @ 2011-01-26 15:53 temper 閱讀(4390) | 評論 (0) | 編輯收藏

Java 理論與實踐: 正確使用 Volatile 變量

Java 語言中的 volatile 變量可以被看作是一種 “程度較輕的 synchronized”；與 synchronized 塊相比，volatile 變量所需的編碼較少，并且運行時開銷也較少，但是它所能實現的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile 變量的模式，并強調了幾種不適合使用 volatile 變量的情形。

鎖提供了兩種主要特性：互斥（mutual exclusion） 和可見性（visibility）。互斥即一次只允許一個線程持有某個特定的鎖，因此可使用該特性實現對共享數據的協調訪問協議，這樣，一次就只有一個線程能夠使用該共享數據。可見性要更加復雜一些，它必須確保釋放鎖之前對共享數據做出的更改對于隨后獲得該鎖的另一個線程是可見的 —— 如果沒有同步機制提供的這種可見性保證，線程看到的共享變量可能是修改前的值或不一致的值，這將引發許多嚴重問題。

Volatile 變量

Volatile 變量具有 synchronized 的可見性特性，但是不具備原子特性。這就是說線程能夠自動發現 volatile 變量的最新值。Volatile 變量可用于提供線程安全，但是只能應用于非常有限的一組用例：多個變量之間或者某個變量的當前值與修改后值之間沒有約束。因此，單獨使用 volatile 還不足以實現計數器、互斥鎖或任何具有與多個變量相關的不變式（Invariants）的類（例如 “start <=end”）。

出于簡易性或可伸縮性的考慮，您可能傾向于使用 volatile 變量而不是鎖。當使用 volatile 變量而非鎖時，某些習慣用法（idiom）更加易于編碼和閱讀。此外，volatile 變量不會像鎖那樣造成線程阻塞，因此也很少造成可伸縮性問題。在某些情況下，如果讀操作遠遠大于寫操作，volatile 變量還可以提供優于鎖的性能優勢。

正確使用 volatile 變量的條件

您只能在有限的一些情形下使用 volatile 變量替代鎖。要使 volatile 變量提供理想的線程安全，必須同時滿足下面兩個條件：

對變量的寫操作不依賴于當前值。
該變量沒有包含在具有其他變量的不變式中。

實際上，這些條件表明，可以被寫入 volatile 變量的這些有效值獨立于任何程序的狀態，包括變量的當前狀態。

第一個條件的限制使 volatile 變量不能用作線程安全計數器。雖然增量操作（x++）看上去類似一個單獨操作，實際上它是一個由讀取－修改－寫入操作序列組成的組合操作，必須以原子方式執行，而 volatile 不能提供必須的原子特性。實現正確的操作需要使 x 的值在操作期間保持不變，而 volatile 變量無法實現這點。（然而，如果將值調整為只從單個線程寫入，那么可以忽略第一個條件。）

大多數編程情形都會與這兩個條件的其中之一沖突，使得 volatile 變量不能像 synchronized 那樣普遍適用于實現線程安全。清單 1 顯示了一個非線程安全的數值范圍類。它包含了一個不變式 —— 下界總是小于或等于上界。

清單 1. 非線程安全的數值范圍類

                

            @NotThreadSafe 

            public class NumberRange {

            private int lower, upper;

            

            public int getLower() { return lower; }

            public int getUpper() { return upper; }

            

            public void setLower(int value) { 

            if (value > upper) 

            throw new IllegalArgumentException(...);

            lower = value;

            }

            

            public void setUpper(int value) { 

            if (value < lower) 

            throw new IllegalArgumentException(...);

            upper = value;

            }

            }

這種方式限制了范圍的狀態變量，因此將 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 —— 這條規則能夠避免將這些模式擴展到不安全的用例。

模式 #1：狀態標志

也許實現 volatile 變量的規范使用僅僅是使用一個布爾狀態標志，用于指示發生了一個重要的一次性事件，例如完成初始化或請求停機。

很多應用程序包含了一種控制結構，形式為 “在還沒有準備好停止程序時再執行一些工作”，如清單 2 所示：

清單 2. 將 volatile 變量作為狀態標志使用

                

            volatile boolean shutdownRequested;

            

            ...

            

            public void shutdown() { shutdownRequested = true; }

            

            public void doWork() { 

            while (!shutdownRequested) { 

            // do stuff

            }

            }

很可能會從循環外部調用 shutdown() 方法 —— 即在另一個線程中 —— 因此，需要執行某種同步來確保正確實現 shutdownRequested 變量的可見性。（可能會從 JMX 偵聽程序、GUI 事件線程中的操作偵聽程序、通過 RMI 、通過一個 Web 服務等調用）。然而，使用 synchronized 塊編寫循環要比使用清單 2 所示的 volatile 狀態標志編寫麻煩很多。由于 volatile 簡化了編碼，并且狀態標志并不依賴于程序內任何其他狀態，因此此處非常適合使用 volatile。

這種類型的狀態標記的一個公共特性是：通常只有一種狀態轉換；shutdownRequested 標志從 false 轉換為 true，然后程序停止。這種模式可以擴展到來回轉換的狀態標志，但是只有在轉換周期不被察覺的情況下才能擴展（從 false 到 true，再轉換到 false）。此外，還需要某些原子狀態轉換機制，例如原子變量。

模式 #2：一次性安全發布（one-time safe publication）

缺乏同步會導致無法實現可見性，這使得確定何時寫入對象引用而不是原語值變得更加困難。在缺乏同步的情況下，可能會遇到某個對象引用的更新值（由另一個線程寫入）和該對象狀態的舊值同時存在。（這就是造成著名的雙重檢查鎖定（double-checked-locking）問題的根源，其中對象引用在沒有同步的情況下進行讀操作，產生的問題是您可能會看到一個更新的引用，但是仍然會通過該引用看到不完全構造的對象）。

實現安全發布對象的一種技術就是將對象引用定義為 volatile 類型。清單 3 展示了一個示例，其中后臺線程在啟動階段從數據庫加載一些數據。其他代碼在能夠利用這些數據時，在使用之前將檢查這些數據是否曾經發布過。

清單 3. 將 volatile 變量用于一次性安全發布

                

            public class BackgroundFloobleLoader {

            public volatile Flooble theFlooble;

            

            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 類型的引用可以確保對象的發布形式的可見性，但是如果對象的狀態在發布后將發生更改，那么就需要額外的同步。

模式 #3：獨立觀察（independent observation）

安全使用 volatile 的另一種簡單模式是：定期 “發布” 觀察結果供程序內部使用。例如，假設有一種環境傳感器能夠感覺環境溫度。一個后臺線程可能會每隔幾秒讀取一次該傳感器，并更新包含當前文檔的 volatile 變量。然后，其他線程可以讀取這個變量，從而隨時能夠看到最新的溫度值。

使用該模式的另一種應用程序就是收集程序的統計信息。清單 4 展示了身份驗證機制如何記憶最近一次登錄的用戶的名字。將反復使用 lastUser 引用來發布值，以供程序的其他部分使用。

清單 4. 將 volatile 變量用于多個獨立觀察結果的發布

                

            public class UserManager {

            public volatile String lastUser;

            

            public boolean authenticate(String user, String password) {

            boolean valid = passwordIsValid(user, password);

            if (valid) {

            User u = new User();

            activeUsers.add(u);

            lastUser = user;

            }

            return valid;

            }

            }

該模式是前面模式的擴展；將某個值發布以在程序內的其他地方使用，但是與一次性事件的發布不同，這是一系列獨立事件。這個模式要求被發布的值是有效不可變的 —— 即值的狀態在發布后不會更改。使用該值的代碼需要清楚該值可能隨時發生變化。

模式 #4：“volatile bean” 模式

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：

清單 5. 遵守 volatile bean 模式的 Person 對象

                

            @ThreadSafe

            public class Person {

            private volatile String firstName;

            private volatile String lastName;

            private volatile int age;

            

            public String getFirstName() { return firstName; }

            public String getLastName() { return lastName; }

            public int getAge() { return age; }

            

            public void setFirstName(String firstName) { 

            this.firstName = firstName;

            }

            

            public void setLastName(String lastName) { 

            this.lastName = lastName;

            }

            

            public void setAge(int age) { 

            this.age = age;

            }

            }

volatile 的高級模式

前面幾節介紹的模式涵蓋了大部分的基本用例，在這些模式中使用 volatile 非常有用并且簡單。這一節將介紹一種更加高級的模式，在該模式中，volatile 將提供性能或可伸縮性優勢。

volatile 應用的的高級模式非常脆弱。因此，必須對假設的條件仔細證明，并且這些模式被嚴格地封裝了起來，因為即使非常小的更改也會損壞您的代碼！同樣，使用更高級的 volatile 用例的原因是它能夠提升性能，確保在開始應用高級模式之前，真正確定需要實現這種性能獲益。需要對這些模式進行權衡，放棄可讀性或可維護性來換取可能的性能收益 —— 如果您不需要提升性能（或者不能夠通過一個嚴格的測試程序證明您需要它），那么這很可能是一次糟糕的交易，因為您很可能會得不償失，換來的東西要比放棄的東西價值更低。

模式 #5：開銷較低的讀－寫鎖策略

目前為止，您應該了解了 volatile 的功能還不足以實現計數器。因為 ++x 實際上是三種操作（讀、添加、存儲）的簡單組合，如果多個線程湊巧試圖同時對 volatile 計數器執行增量操作，那么它的更新值有可能會丟失。

然而，如果讀操作遠遠超過寫操作，您可以結合使用內部鎖和 volatile 變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計數器使用 synchronized 確保增量操作是原子的，并使用 volatile 保證當前結果的可見性。如果更新不頻繁的話，該方法可實現更好的性能，因為讀路徑的開銷僅僅涉及 volatile 讀操作，這通常要優于一個無競爭的鎖獲取的開銷。

清單 6. 結合使用 volatile 和 synchronized 實現 “開銷較低的讀－寫鎖”

                

            @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 int value;

            

            public int getValue() { return value; }

            

            public synchronized int increment() {

            return value++;

            }

            }

之所以將這種技術稱之為 “開銷較低的讀－寫鎖” 是因為您使用了不同的同步機制進行讀寫操作。因為本例中的寫操作違反了使用 volatile 的第一個條件，因此不能使用 volatile 安全地實現計數器 —— 您必須使用鎖。然而，您可以在讀操作中使用 volatile 確保當前值的可見性，因此可以使用鎖進行所有變化的操作，使用 volatile 進行只讀操作。其中，鎖一次只允許一個線程訪問值，volatile 允許多個線程執行讀操作，因此當使用 volatile 保證讀代碼路徑時，要比使用鎖執行全部代碼路徑獲得更高的共享度 —— 就像讀－寫操作一樣。然而，要隨時牢記這種模式的弱點：如果超越了該模式的最基本應用，結合這兩個競爭的同步機制將變得非常困難。

結束語

與鎖相比，Volatile 變量是一種非常簡單但同時又非常脆弱的同步機制，它在某些情況下將提供優于鎖的性能和伸縮性。如果嚴格遵循 volatile 的使用條件 —— 即變量真正獨立于其他變量和自己以前的值 —— 在某些情況下可以使用 volatile 代替 synchronized 來簡化代碼。然而，使用 volatile 的代碼往往比使用鎖的代碼更加容易出錯。本文介紹的模式涵蓋了可以使用 volatile 代替 synchronized 的最常見的一些用例。遵循這些模式（注意使用時不要超過各自的限制）可以幫助您安全地實現大多數用例，使用 volatile 變量獲得更佳性能。

http://www.ibm.com/developerworks/cn/java/j-jtp06197.html

posted @ 2010-12-20 14:02 temper 閱讀(244) | 評論 (0) | 編輯收藏

win2008r2系統日志拷貝問題

java調用bat，用xcopy拷貝系統日志到指定目錄。如果jdk版本是32位，因為微軟做了系統重定向，不能拷貝過去。
將%WinDir%\System32\Winevt\Logs\Application.evtx修改為%WinDir%\Sysnative\Winevt\Logs\Application.evtx，即可實現。
參考資料：http://support.microsoft.com/kb/942589/

posted @ 2010-07-26 13:09 temper 閱讀(1023) | 評論 (0) | 編輯收藏

轉：如何用javaAPI取得java進程的PID

http://blog.csdn.net/watchnight/archive/2010/01/26/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

posted @ 2010-07-01 16:06 temper 閱讀(1014) | 評論 (0) | 編輯收藏

JavaService在win2008r2下不能啟動

將jvm.dll拷貝到JavaService.exe所在目錄（也可以通過設置path實現）
參照：http://forge.ow2.org/forum/forum.php?thread_id=2330&forum_id=625

ps：推薦通過設置path來實現，畢竟這樣對用戶和空間需求改動最小。
參照：http://www.tmro.net/2008/05/jboss-service-on-windows-server-2003/

posted @ 2010-06-25 14:28 temper 閱讀(383) | 評論 (0) | 編輯收藏

JVM調優總結（轉）

原文：http://roylone.blog.163.com/blog/static/378674132008816104325127/

一、相關概念

基本回收算法

引用計數（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類型
GC有兩種類型：Scavenge GC和Full GC。

Scavenge GC
一般情況下，當新對象生成，并且在Eden申請空間失敗時，就好觸發Scavenge GC，堆Eden區域進行GC，清除非存活對象，并且把尚且存活的對象移動到Survivor區。然后整理Survivor的兩個區。
Full GC
對整個堆進行整理，包括Young、Tenured和Perm。Full GC比Scavenge GC要慢，因此應該盡可能減少Full GC。有如下原因可能導致Full GC：
- Tenured被寫滿
- Perm域被寫滿
- System.gc()被顯示調用
- 上一次GC之后Heap的各域分配策略動態變化

分代垃圾回收過程演示

二、垃圾回收器

目前的收集器主要有三種：串行收集器、并行收集器、并發收集器。

串行收集器

使用單線程處理所有垃圾回收工作，因為無需多線程交互，所以效率比較高。但是，也無法使用多處理器的優勢，所以此收集器適合單處理器機器。當然，此收集器也可以用在小數據量（100M左右）情況下的多處理器機器上。可以使用-XX:+UseSerialGC打開。
并行收集器
1. 對年輕代進行并行垃圾回收，因此可以減少垃圾回收時間。一般在多線程多處理器機器上使用。使用-XX:+UseParallelGC. 打開。并行收集器在J2SE5.0第六6更新上引入，在Java SE6.0中進行了增強--可以堆年老代進行并行收集。如果年老代不使用并發收集的話，是使用單線程進行垃圾回收，因此會制約擴展能力。使用-XX:+UseParallelOldGC打開。
2. 使用-XX:ParallelGCThreads=<N>設置并行垃圾回收的線程數。此值可以設置與機器處理器數量相等。
3. 此收集器可以進行如下配置：
  - 最大垃圾回收暫停:指定垃圾回收時的最長暫停時間，通過-XX:MaxGCPauseMillis=<N>指定。<N>為毫秒.如果指定了此值的話，堆大小和垃圾回收相關參數會進行調整以達到指定值。設定此值可能會減少應用的吞吐量。
  - 吞吐量:吞吐量為垃圾回收時間與非垃圾回收時間的比值，通過-XX:GCTimeRatio=<N>來設定，公式為1/（1+N）。例如，-XX:GCTimeRatio=19時，表示5%的時間用于垃圾回收。默認情況為99，即1%的時間用于垃圾回收。
并發收集器
可以保證大部分工作都并發進行（應用不停止），垃圾回收只暫停很少的時間，此收集器適合對響應時間要求比較高的中、大規模應用。使用-XX:+UseConcMarkSweepGC打開。
1. 并發收集器主要減少年老代的暫停時間，他在應用不停止的情況下使用獨立的垃圾回收線程，跟蹤可達對象。在每個年老代垃圾回收周期中，在收集初期并發收集器會對整個應用進行簡短的暫停，在收集中還會再暫停一次。第二次暫停會比第一次稍長，在此過程中多個線程同時進行垃圾回收工作。
2. 并發收集器使用處理器換來短暫的停頓時間。在一個N個處理器的系統上，并發收集部分使用K/N個可用處理器進行回收，一般情況下1<=K<=N/4。
3. 在只有一個處理器的主機上使用并發收集器，設置為incremental mode模式也可獲得較短的停頓時間。
4. 浮動垃圾：由于在應用運行的同時進行垃圾回收，所以有些垃圾可能在垃圾回收進行完成時產生，這樣就造成了“Floating Garbage”，這些垃圾需要在下次垃圾回收周期時才能回收掉。所以，并發收集器一般需要20%的預留空間用于這些浮動垃圾。
5. Concurrent Mode Failure：并發收集器在應用運行時進行收集，所以需要保證堆在垃圾回收的這段時間有足夠的空間供程序使用，否則，垃圾回收還未完成，堆空間先滿了。這種情況下將會發生“并發模式失敗”，此時整個應用將會暫停，進行垃圾回收。
6. 啟動并發收集器：因為并發收集在應用運行時進行收集，所以必須保證收集完成之前有足夠的內存空間供程序使用，否則會出現“Concurrent Mode Failure”。通過設置-XX:CMSInitiatingOccupancyFraction=<N>指定還有多少剩余堆時開始執行并發收集
小結
- 串行處理器：
  --適用情況：數據量比較小（100M左右）；單處理器下并且對響應時間無要求的應用。
  --缺點：只能用于小型應用
- 并行處理器：
  --適用情況：“對吞吐量有高要求”，多CPU、對應用響應時間無要求的中、大型應用。舉例：后臺處理、科學計算。
  --缺點：應用響應時間可能較長
- 并發處理器：
  --適用情況：“對響應時間有高要求”，多CPU、對應用響應時間有較高要求的中、大型應用。舉例：Web服務器/應用服務器、電信交換、集成開發環境。

三、常見配置舉例

堆大小設置
JVM 中最大堆大小有三方面限制：相關操作系統的數據模型（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。更具應用的線程所需內存大小進行調整。在相同物理內存下，減小這個值能生成更多的線程。但是操作系統對一個進程內的線程數還是有限制的，不能無限生成，經驗值在3000~5000左右。
- java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
  -XX:NewRatio=4: 設置年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設置為4，則年輕代與年老代所占比值為1：4，年輕代占整個堆棧的 1/5-XX:SurvivorRatio=4：設置年輕代中 Eden區與Survivor區的大小比值。設置為4，則兩個Survivor區與一個Eden區的比值為2:4，一個Survivor區占整個年輕代的 1/6
  -XX:MaxPermSize=16m:設置持久代大小為16m。
  -XX:MaxTenuringThreshold=0：設置垃圾最大年齡。如果設置為0的話，則年輕代對象不經過Survivor區，直接進入年老代。對于年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概論。
回收器選擇
JVM給了三種選擇：串行收集器、并行收集器、并發收集器，但是串行收集器只適用于小數據量的情況，所以這里的選擇主要針對并行收集器和并發收集器。默認情況下，JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啟動時加入相應參數。JDK5.0以后，JVM會根據當前系統配置進行判斷。
1. 吞吐量優先的并行收集器
  如上文所述，并行收集器主要以到達一定的吞吐量為目標，適用于科學技術和后臺處理等。
  典型配置：
  - 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區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用并行收集器時，一直打開。
2. 響應時間優先的并發收集器
  如上文所述，并發收集器主要是保證系統的響應時間，減少垃圾收集時的停頓時間。適用于應用服務器、電信領域等。
  典型配置：
  - 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->113543K(130112K), 0.0094143 secs]
  [Full GC 121376K->10414K(130112K), 0.0650971 secs]
- -XX:+PrintGCDetails
  輸出形式：[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]
  [GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]
- -XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps可與上面兩個混合使用
  輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
- -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中斷的執行時間。可與上面混合使用
  輸出形式：Application time: 0.5291524 seconds
- -XX:+PrintGCApplicationStoppedTime：打印垃圾回收期間程序暫停的時間。可與上面混合使用
  輸出形式：Total time for which application threads were stopped: 0.0468229 seconds
- -XX:PrintHeapAtGC:打印GC前后的詳細堆棧信息
  輸出形式：
  34.702: [GC {Heap before gc invocations=7:
  def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K, 99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
  from space 6144K, 55% used [0x221d0000, 0x22527e10, 0x227d0000)
  to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
  tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
  the space 69632K,   3% used [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
  compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
     the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
      ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
      rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
  34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
  def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
  eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
  from space 6144K, 55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
  to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
  tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
  the space 69632K,   4% used [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
  compacting perm gen total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
     the space 8192K, 35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
      ro space 8192K, 66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
      rw space 12288K, 46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
  }
  , 0.0757599 secs]
- -Xloggc:filename:與上面幾個配合使用，把相關日志信息記錄到文件以便分析。
常見配置匯總
1. 堆設置
  - -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:設置持久代大小
2. 收集器設置
  - -XX:+UseSerialGC:設置串行收集器
  - -XX:+UseParallelGC:設置并行收集器
  - -XX:+UseParalledlOldGC:設置并行年老代收集器
  - -XX:+UseConcMarkSweepGC:設置并發收集器
3. 垃圾回收統計信息
  - -XX:+PrintGC
  - -XX:+PrintGCDetails
  - -XX:+PrintGCTimeStamps
  - -Xloggc:filename
4. 并行收集器設置
  - -XX:ParallelGCThreads=n:設置并行收集器收集時使用的CPU數。并行收集線程數。
  - -XX:MaxGCPauseMillis=n:設置并行收集最大暫停時間
  - -XX:GCTimeRatio=n:設置垃圾回收時間占程序運行時間的百分比。公式為 1/(1+n)
5. 并發收集器設置
  - -XX:+CMSIncrementalMode:設置為增量模式。適用于單CPU情況。
  - -XX:ParallelGCThreads=n:設置并發收集器年輕代收集方式為并行收集時，使用的CPU數。并行收集線程數。

四、調優總結

年輕代大小選擇
- 響應時間優先的應用：盡可能設大，直到接近系統的最低響應時間限制（根據實際情況選擇）。在此種情況下，年輕代收集發生的頻率也是最小的。同時，減少到達年老代的對象。
- 吞吐量優先的應用：盡可能的設置大，可能到達Gbit的程度。因為對響應時間沒有要求，垃圾收集可以并行進行，一般適合8CPU以上的應用。
年老代大小選擇
- 響應時間優先的應用：年老代使用并發收集器，所以其大小需要小心設置，一般要考慮并發會話率和會話持續時間等一些參數。如果堆設置小了，可以會造成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；如果堆大了，則需要較長的收集時間。最優化的方案，一般需要參考以下數據獲得：
  - 并發垃圾收集信息
  - 持久代并發收集次數
  - 傳統GC信息
  - 花在年輕代和年老代回收上的時間比例
  減少年輕代和年老代花費的時間，一般會提高應用的效率
- 吞吐量優先的應用：一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。原因是，這樣可以盡可能回收掉大部分短期對象，減少中期的對象，而年老代盡存放長期存活對象。
較小堆引起的碎片問題
因為年老代的并發收集器使用標記、清除算法，所以不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合并，這樣可以分配給較大的對象。但是，當堆空間較小時，運行一段時間以后，就會出現“碎片”，如果并發收集器找不到足夠的空間，那么并發收集器將會停止，然后使用傳統的標記、清除方式進行回收。如果出現“碎片”，可能需要進行如下配置：
- -XX:+UseCMSCompactAtFullCollection：使用并發收集器時，開啟對年老代的壓縮。
- -XX:CMSFullGCsBeforeCompaction=0：上面配置開啟的情況下，這里設置多少次Full GC后，對年老代進行壓縮

posted @ 2010-06-25 14:21 temper 閱讀(164) | 評論 (0) | 編輯收藏

response.setHeader(...)下載中文文件名亂碼問題(轉)

http://blog.csdn.net/ai_33/archive/2008/06/10/2529096.aspx

關于中文文件下載的問題，網上的咨詢和答疑已經很多，我原來處理下載的代碼如下：

    response.setHeader("Content-Disposition", "attachment; filename=" + java.net.URLEncoder.encode(fileName, "UTF-8"));
下載的程序里有了這句，一般在IE6的下載提示框上將正確顯示文件的名字，無論是簡體中文，還是日文。不過當時確實沒有仔細測試文件名很長的中文文件名。先如今經過仔細測試，發現文字只要超過17個字，就不能下載了。經過好一番google和反復測試，總算對這個問題有了系統的認識，分列如下：

    一. 通過我原來的方式，也就是先用URLEncoder編碼，當中文文字超過17個時，IE6 無法下載文件。這是IE的bug，參見微軟的知識庫文章 KB816868 。原因可能是因為ie在處理 Response Header 的時候，對header的長度限制在150字節左右。而一個漢字編碼成UTF-8是9個字節，那么17個字便是153個字節，所以便會報錯。微軟提供了一個補丁，可以從這里下載。這個補丁需要先安裝ie6 sp1。因為我平時勤打補丁，我的IE6版本號是 6.0.2800.1106.xpsp2_xxxxx。所以我可能已經安裝過了補丁，從而可以下載，但仍然出現文件名被截斷的現象。微軟讓我們等待IE下一個service pack的發布。我今天也上網看到了好消息，迫于firefox的壓力，IE7可能在年中發布。另外，Firefox 不支持這樣的方式，將把編碼后的%xx%xx直接作為文件名顯示。

    二. 我嘗試使用 javamail 的MimeUtility.encode()方法來編碼文件名，也就是編碼成 =?gb2312?B?xxxxxxxx?= 這樣的形式，并從 RFC1522 中找到對應的標準支持。不過很遺憾，IE6并不支持這一個標準。我試了一下，Firefox是支持的。

    三. 按網上很多人提供的解決方案：將文件名編碼成ISO8859-1似乎是有效的解決方案，代碼如下：

    response.setHeader( "Content-Disposition", "attachment;filename=" + new String( fileName.getBytes("gb2312"), "ISO8859-1" ) );

    在確保附件文件名都是簡體中文字的情況下，那么這個辦法確實是最有效的，不用讓客戶逐個的升級IE。如果臺灣同胞用，把gb2312改成big5就行。但現在的系統通常都加入了國際化的支持，普遍使用UTF-8。如果文件名中又有簡體中文字，又有繁體中文，還有日文。那么亂碼便產生了。另外，在我的電腦上Firefox(v1.0-en)下載也是亂碼。

    折中考慮，我結合了一、三的方式，代碼片斷如下：

        String fileName = URLEncoder.encode(atta.getFileName(), "UTF-8");
        /*
         * see http://support.microsoft.com/default.aspx?kbid=816868
         */
        if (fileName.length() > 150) {
            String guessCharset = xxxx /*根據request的locale 得出可能的編碼，中文操作系統通常是gb2312*/
            fileName = new String(atta.getFileName().getBytes(guessCharset), "ISO8859-1");
        }
        response.setHeader("Content-Disposition", "attachment; filename=" + fileName);

    暫且不考慮 Firefox 是因為它目前似乎還沒有有力侵食到IE的企業用戶市場。影響客戶買單的常常是進度，而不是兼容度。

posted @ 2009-05-08 17:30 temper 閱讀(1359) | 評論 (0) | 編輯收藏

常用鏈接

留言簿

隨筆檔案

文章檔案

搜索

最新評論

閱讀排行榜

評論排行榜