<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    posts - 23,  comments - 3,  trackbacks - 0
      2009年3月27日
    win7自動(dòng)升級(jí)到了ie11,但是debug工具太難用了,準(zhǔn)備會(huì)退到9,但是在添加刪除程序里,把ie11的功能關(guān)閉,安裝9時(shí),提示ie已經(jīng)安裝。
    并且ie圖標(biāo)也沒了。。progrem files下面的ie啟動(dòng)程序也沒了。。。。

    最好在這找到了卸載的辦法
    http://www.iefans.net/windows-7-ie11-wufa-xiezai-chongxin-anzhuang-gengxin-banben/
    posted @ 2014-02-10 18:43 temper 閱讀(4213) | 評(píng)論 (1)編輯 收藏
    工作中用到了struts2的tabbedpanel標(biāo)簽。
    在火狐和chrome下都沒問題,但是在ie下報(bào)錯(cuò):
    SCRIPT5007: 無法獲取未定義或 null 引用的屬性“toLowerCase” 
                   struts_dojo.js, 行6471 字符1。
    針對(duì)struts_dojo.js進(jìn)行debug,發(fā)現(xiàn)6470行的“node.scopeName”是undefined。

    直接修改此js代碼,增加“&&typeof(node.scopeName)!='undefined'”,
    重新做成struts2-dojo-plugin.jar,問題解決
    posted @ 2013-11-20 17:10 temper 閱讀(2630) | 評(píng)論 (2)編輯 收藏
    JVM的-XX:[+/-]<option>以前竟然沒注意,mark一個(gè):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) | 評(píng)論 (0)編輯 收藏
    昨天配了兩個(gè)weblogic節(jié)點(diǎn),但是怎么也啟動(dòng)不起來。以前這種操作做了十幾次了,沒遇到過這種問題。
    錯(cuò)誤如下:
    weblogic.security.SecurityInitializationException: 認(rèn)証が拒否されました。起動(dòng)アイデンティティが有効ではありません。起動(dòng)アイデンティティ?ファイル(boot.properties)のユーザー名またはパスワード(もしくはその雙方)が有効ではありません。起動(dòng)アイデンティティ?ファイルが作成された後に起動(dòng)アイデンティティが変更されていることが考えられます。適切な値のユーザー名およびパスワードで起動(dòng)アイデンティティ?ファイルを編集および更新してください。更新された起動(dòng)アイデンティティ?ファイルを使用して初めてサーバーを起動(dòng)するときには、それらの値は暗號(hào)化されます。
        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の認(rèn)証が失敗しました。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)
    提示用戶名和密碼問題,但是用戶名和密碼我很確頂沒錯(cuò)。

    然后根據(jù)這里:
    http://bbs.weblogicfans.net/viewthread.php?tid=399&extra=&ordertype=1&page=4
    增加了啟動(dòng)參數(shù)t3://AdminServerIP:AdminServerPort(以前都是系統(tǒng)默認(rèn)),發(fā)現(xiàn)啟動(dòng)成功。
    查看startManagedWebLogic.cmd,發(fā)現(xiàn)41行
    set ADMIN_URL=XXX,竟然用的是計(jì)算機(jī)名。。。。。。。。。。。

    測(cè)試機(jī)裝完環(huán)境,配置集群時(shí),為了便于辨認(rèn),修改了計(jì)算機(jī)名,悲劇的根源。。。。。。
    然后發(fā)現(xiàn)stopManagedWebLogic.cmd里面用的也是計(jì)算機(jī)名。。。。。。

    計(jì)算機(jī)名,ip都可能被改,我感覺弄個(gè)localhost比啥都強(qiáng),實(shí)在不明白這么做得原因是啥。

    不過以后搭建環(huán)境時(shí),一定要先把系統(tǒng)要修改的做完,然后再裝其他軟件。
    posted @ 2012-01-31 11:25 temper 閱讀(2874) | 評(píng)論 (0)編輯 收藏

    在HP-UX操作系統(tǒng)中使用-d32或-d64來指定使用Java應(yīng)用程序使用32bit的JVM還是使用64bit的JVM(默認(rèn)32bit).
    一個(gè)Java應(yīng)用程序運(yùn)行時(shí),它會(huì)根據(jù)自己所在的HP-UX使用的CPU類型及指定的JVM位數(shù)(-d32 or保持默認(rèn)、-d64)使用$JAVA_HOME/java(殼)自動(dòng)選擇要執(zhí)行的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中兩個(gè)腳本的MEM_ARGS參數(shù)值,在此參數(shù)值的最前面加上-64參數(shù)即可,例如:
    MEM_ARGS=”-d64 –Xms512m –Xmx1024m…”

    WebLogic Serevr 9.x and later version:
    修改${Domain_home}/bin/下的setDomainEnv.sh腳本MEM_ARGS參數(shù)值,在此參數(shù)值的最前面加上-64參數(shù)即可。

    轉(zhuǎn)載自


    posted @ 2011-09-27 14:44 temper 閱讀(1585) | 評(píng)論 (0)編輯 收藏
    最近的項(xiàng)目涉及到了JAVA需要調(diào)用C程序的問題。主要是調(diào)用C寫的加密算法。
    主要解決方案是應(yīng)用JNI去調(diào)用C生成的so庫
    用eclispe新建一個(gè)java project項(xiàng)目,項(xiàng)目名稱為spidHandle,注意下面VC的項(xiàng)目名稱也是spidHandle,他們分別是用eclispe和VC6.0創(chuàng)建的,不是同個(gè)項(xiàng)目。
    編寫一個(gè)JNI入口類SpidHandle.java:
    Java代碼  收藏代碼
    1. package com.spidHandle.api;  
    2. public class SpidHandle {  
    3.         static {  
    4.                 System.loadLibrary("spidhandle");  
    5.         }  
    6.           
    7.         public String buildSpID(String path, String login_name, String password, String key)  
    8.         {  
    9.             return getSPID(path, login_name, password, key);  
    10.         }  
    11.           
    12.         public native String getSPID(String path, String login_name, String password, String key);  
    13.   
    14.     /** 
    15.      * @param args 
    16.      *  
    17.      * 供測(cè)試用 
    18.      */  
    19.     public static void main(String[] args) {  
    20.         // TODO Auto-generated method stub  
    21.         String keyforMD5 = "A6EIo8tuaKS";  
    22.         String s = new SpidHandle().buildSpID("/test", "test", "test", keyforMD5);  
    23.         System.out.println(s);  
    24.     }  
    25.   
    26. }  


    通過CMD命令窗口,CMD命令窗口定位到SpidHandle.java的目錄下,編譯SpidHandle.java文件:
    Java代碼  收藏代碼
    1. javac SpidHandle.java  

    執(zhí)行JAVAC命令后,在同個(gè)文件目錄下生成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窗口中執(zhí)行
    Java代碼  收藏代碼
    1. javah com.spidHandle.api.SpidHandle  

    執(zhí)行后在Z:\project\work_workspace\spidhandle\src目錄下生成文件
    com_spidHandle_api_SpidHandle.h文件。
    安裝VC6.0開發(fā)工具。如果你是在windows下開發(fā),那可以先生成DLL,這樣你就可以在Windows下調(diào)試。其實(shí)JNI調(diào)用DLL和SO是一樣的,只是運(yùn)行的操作系統(tǒng)不一樣而已。下面是如何用VC6.0創(chuàng)建一個(gè)DLL項(xiàng)目。
    創(chuàng)建一個(gè)項(xiàng)目工程,名為spidhandle的工程,創(chuàng)建過程如下:
    1、打開VC6.0->文件->新建
    2、在彈出窗口中的工程選項(xiàng)卡中選擇Win32 Dynamic-Link Library;工程名命名為spidhandle;點(diǎn)擊確定。
    3、在新的提示窗口中選擇一個(gè)空白的DLL工程,點(diǎn)擊完成。
    4、在菜單的工具欄中選擇選項(xiàng),彈出選項(xiàng)窗口。切換到目錄選項(xiàng)卡
    5、在目錄選項(xiàng)卡中新建目錄,新建的目錄為你JDK所在的目錄下的include目錄,如:
       D:\Program Files\Java\jdk1.6.0_16\include
      再新建一個(gè)目錄,新建的目錄為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頭文件對(duì)應(yīng)的cpp文件, 文件名稱為com_spidHandle_api_SpidHandle.cpp,然后返回VC6.0操作界面,將其添加到工程的Source Files,右鍵工程窗口中的Source Files,選擇添加文件到目錄下,選擇工程路徑下的com_spidHandle_api_SpidHandle.cpp文件。
    Java代碼  收藏代碼
    1. #include "com_spidHandle_api_SpidHandle.h"  
    2. #include <string.h>  
    3.   
    4. #include "MD5.h"  
    5.   
    6. const static char* version = "1201.01";  
    7.   
    8. JNIEXPORT jstring JNICALL Java_com_spidHandle_api_SpidHandle_getSPID  
    9.  (JNIEnv *env , jobject obj, jstring path, jstring login_name, jstring password, jstring key)  
    10. {  
    11.     printf("-= com_spidHandle_api_SpidHandle Version  %s =- \n", version);  
    12.     char icpid[256];  
    13.     const char * md5="A6EIo8tuaKS";  
    14.   
    15.     const char* login_user = env->GetStringUTFChars(login_name, false);  
    16.     const char* login_pwd = env->GetStringUTFChars(password, false);  
    17.     const char* md5_key = env->GetStringUTFChars(key, false);  
    18.     const char* path_str = env->GetStringUTFChars(path, false);  
    19.       
    20.     memset(icpid, 0, 256);  
    21.   
    22.     printf("login_user = %s\n", login_user);  
    23.     printf("path = %s\n", path_str);  
    24.     printf("login_pwd = %s\n", login_pwd);  
    25.     printf("md5_key = %s\n", md5_key);    
    26.   
    27.     // 不管播放哪個(gè)url 直接用這個(gè)加密  -_-||   
    28.     // pPath = "tmes_224";  
    29.     // 組建加密部分  
    30.     char *p=icpid;  
    31.     *p=strlen(login_user);  
    32.     p++;  
    33.     strcpy(p,login_user);  
    34.     p+=strlen(login_user);  
    35.     *p=strlen(path_str);  
    36.     p++;  
    37.     strcpy(p,path_str);  
    38.     p+=strlen(path_str);  
    39.       
    40.     if(strlen(md5_key) > 1)  
    41.         md5 = md5_key;  
    42.     *p=strlen(md5);  
    43.     p++;  
    44.     strcpy(p,md5);  
    45.     p+=strlen(md5);  
    46.   
    47.     MD5 m1;  
    48.     m1 << md5 << login_user << login_pwd;  
    49.   
    50.     const char *pmd5 = m1.HexDigest();  // symbian專用  
    51.     char md5buf[256];  
    52.     memset(md5buf,0,256);  
    53.     memcpy( md5buf,pmd5,strlen(pmd5) ); // 結(jié)束symbian專用  
    54.   
    55.     printf("md5buf = %s\n", md5buf);  
    56.       
    57.     int pmd5_len = strlen(pmd5);  
    58.   
    59.     *p=strlen(md5buf);  
    60.     p++;  
    61.     strcpy(p,md5buf);  
    62.     p+=strlen(md5buf);  
    63.   
    64.     printf("spid = %s\n", icpid);  
    65.   
    66.     return env->NewStringUTF(icpid);  
    67. }  

    8、將MD5.h,MD5.cpp拷貝到工程目錄下,即跟com_spidHandle_api_SpidHandle.h文件同在項(xiàng)目根目錄下。這兩個(gè)文件其實(shí)是我用到的加密類。不是VC自有的,是另外同事開發(fā)的。
    9、在VC6.0的菜單欄中選擇組建;在工程文件夾下的Debug文件夾中生成spidHandle.dll
    10、可以將spidHandle.dll拷貝到JAVA PROJECT的spidHandle的項(xiàng)目里,放在項(xiàng)目的根目錄,即Z:\project\work_workspace\spidhandle目錄 下,用eclispe運(yùn)行SpidHandle.java文件。在輸出窗口中會(huì)打印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文件夾下,執(zhí)行:
    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 表示需要引入的頭文件。相當(dāng)于生成DLL引入了jni.h等文件。-fPIC表示生成共享庫文件,libspidhandle.so表示庫文件名。
    3、執(zhí)行export LD_LIBRARY_PATH=/home/spidHandle
      此步是設(shè)置將庫文件所在路徑加入LD_LIBRARY_PATH中去,如果不執(zhí)行此步,在運(yùn)行中就會(huì)出現(xiàn)異常:
    Java代碼  收藏代碼
    1. java.lang.UnsatisfiedLinkError: no XXX in java.library.path  

    4、可以在Linux中部署一個(gè)簡(jiǎn)單的web 應(yīng)用,如一個(gè)簡(jiǎn)單的test項(xiàng)目,在servlet中調(diào)用該so,調(diào)用代碼如下:
    Java代碼  收藏代碼
    1. String spid = new SpidHandle().buildSpID(pathforMD5, user,pwd,keyforMD5);  

    spid為加密后返回的結(jié)果。


    補(bǔ)充:
    過程中所碰到的問題:

    問題1
    java.lang.UnsatisfiedLinkError: /home/spidhandle/libspidhandle.so: /home/spidhandle/libspidhandle.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)

    在linux中,用servlet調(diào)用該so,出現(xiàn)上面的異常,主要因?yàn)槲宜渴饝?yīng)用的linux服務(wù)器是64位的,而所生成的so是32位的,后來將項(xiàng)目部署到32位的服務(wù)器上就解決問題了。
    如何查看linux操作系統(tǒng)是32位還是64位的,可以運(yùn)行下面命令:
    查看操作系統(tǒng)位數(shù)
    Java代碼  收藏代碼
    1. file /bin/ls  


    問題2
    運(yùn)行servlet,JVM崩潰,并輸出JVM異常,異常文件在tomcat啟動(dòng)文件startup.sh同個(gè)目錄下,如tomcat/bin下,文件格式為hs_err_pid*.log 如,hs_err_pid23600.log
    錯(cuò)誤日志內(nèi)容:
    #
    # 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的對(duì)象,但后來發(fā)現(xiàn)
    Java代碼  收藏代碼
    1. Heap  
    2.  PSYoungGen      total 24448K, used 339K [0xb0420000, 0xb1da0000, 0xb3900000)  
    3.   eden space 23168K, 1% used [0xb0420000,0xb0474cf8,0xb1ac0000)  
    4.   from space 1280K, 0% used [0xb1c20000,0xb1c20000,0xb1d60000)  
    5.   to   space 1408K, 0% used [0xb1ac0000,0xb1ac0000,0xb1c20000)  
    6.  PSOldGen        total 27072K, used 8597K [0x95d00000, 0x97770000, 0xb0420000)  
    7.   object space 27072K, 31% used [0x95d00000,0x96565510,0x97770000)  
    8.  PSPermGen       total 19200K, used 11186K [0x91d00000, 0x92fc0000, 0x95d00000)  
    9.   object space 19200K, 58% used [0x91d00000,0x927ec980,0x92fc0000)  


    并沒有出現(xiàn)堆棧縊出的現(xiàn)象,所以排除該原因。

    查閱 文檔:
          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.
         
          解決方法:
          啟動(dòng)JVM時(shí)增加啟動(dòng)參數(shù) -Xcheck:jni
          日志中輸出JNI的錯(cuò)誤日志:
         
    Java代碼  收藏代碼
    1. FATAL ERROR in native method: JNI string operation received a non-string  
    2. at com.spidHandle.api.SpidHandle.getSPID(Native Method)  
    3. at com.spidHandle.api.SpidHandle.buildSpID(SpidHandle.java:12)  
    4. at com.play.servlet.PlayServlet.service(PlayServlet.java:190)  
    5. at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)  
    6. at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)  
    7. at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)  
    8. at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)  
    9. at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)  
    10. at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)  
    11. at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)  
    12. at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)  
    13. at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861)  
    14. at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579)  
    15. at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584)  
    16. at java.lang.Thread.run(Thread.java:619)
    JVM崩潰的原因找到了.是由于傳入C方法體中某個(gè)參數(shù)值為NULL,如buildSpID(String path, String login_name, String password, String key)中l(wèi)ogin_name為NULL,導(dǎo)致傳遞給C程序的參數(shù)為NULL.NULL值傳遞給C,C不能識(shí)別他為字符串,所以JVM崩潰.

    http://zhxmyself.iteye.com/blog/961249
    posted @ 2011-09-27 14:42 temper 閱讀(6195) | 評(píng)論 (0)編輯 收藏
    今天客戶發(fā)過來一個(gè)新的jar包B.jar,讓我替換原來的進(jìn)行測(cè)試,但是替換完畢執(zhí)行后,出現(xiàn)如下錯(cuò)誤:
    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)

    網(wǎng)上搜了一圈,大部分說引入的jar包呢有相同類名的類,所以loader的時(shí)候出現(xiàn)錯(cuò)誤。

    但是目前做的一個(gè)小產(chǎn)品,只有兩個(gè)jar包,A.jar和前文提到的B.jar,沒有引入第三方包。我仔細(xì)查了一下兩個(gè)jar包,不存在相同類名的情況。

    最后發(fā)現(xiàn)這個(gè)問題很多時(shí)候和數(shù)字簽名這個(gè)關(guān)鍵字一起出現(xiàn)。然后仔細(xì)檢查,發(fā)現(xiàn)新的B.jar里面忘記加數(shù)字簽名了。

    把A.jar里面的數(shù)字簽名刪除,運(yùn)行正常。

    目前在等待加完數(shù)字簽名的B.jar,也在查資料尋找出現(xiàn)此問題的原因,未完待續(xù)。
    posted @ 2011-08-18 18:53 temper 閱讀(5112) | 評(píng)論 (0)編輯 收藏

    進(jìn)程只是提供了一段地址空間和內(nèi)核對(duì)象,其運(yùn) 行時(shí)通過其他地址空間內(nèi)的主線程來體現(xiàn)的。當(dāng)主線程的進(jìn)入點(diǎn)函數(shù)返回時(shí),進(jìn)程也就隨之而技術(shù)。這種進(jìn)程的種植方式是進(jìn)程的正常退出。進(jìn)程中的所有縣城資源 都能夠得到正確的清除。除了這種進(jìn)程的正常退出方式之外,優(yōu)勢(shì)還需要在程序中通過代碼來強(qiáng)制結(jié)束本進(jìn)程或其他進(jìn)程的運(yùn)行。

    ExitProcess

    void ExitProcess(UINT uExitCode);

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

    有鑒于ExitProcess()函數(shù)的強(qiáng)制性和安全性,在使用時(shí)一定要引起注意。

    Terminateprocess()

    ExitProcess 只能強(qiáng)制本進(jìn)程的推出,如果要在一個(gè)進(jìn)程中強(qiáng)制結(jié)束其他的進(jìn)程就需要用TerminateProcess()來實(shí)現(xiàn),與ExitProcess()不 同,TerminateProcess()函數(shù)執(zhí)行后,被終止的進(jìn)程不會(huì)得到任何關(guān)于程序退出的通知。也就是說,被終止的進(jìn)程是無法再結(jié)束運(yùn)行前進(jìn)程推出 前的收尾工作的。所以,通常只有在其他任何地方都無法迫使進(jìn)程退出時(shí)才會(huì)考慮使用TerminateProcess()去強(qiáng)制結(jié)束進(jìn)程。

    BOOL TerminateProcess(HANDLE hProcess, UINT uExitCode);

    參 數(shù)hProcess和uExitCode分別為進(jìn)城句柄和退出代碼。如果被結(jié)束的是本進(jìn)程,可以通過GetCurrentProcess()獲取到句柄。 TerminateProcess()是異步執(zhí)行的,在調(diào)用后返回并不能確定被終止進(jìn)程是否已經(jīng)真的退出,如果調(diào)用TerminateProcess() 的進(jìn)程對(duì)此細(xì)節(jié)關(guān)心,可以通過WaitForSingleObject()來等待進(jìn)程的真正結(jié)束。

    在VC中如何結(jié)束系統(tǒng)正在運(yùn)行的其他進(jìn)程(該進(jìn)程必須有窗口界面),其實(shí)很簡(jiǎn)單,按照如下步驟進(jìn)程:

    1)取得進(jìn)程的句柄(利用FindWindow函數(shù)得到);

    2)獲取進(jìn)程ID號(hào)(用GetWindowThreadProcessId函數(shù)獲取);

    3)打開進(jìn)程,OpenProcess函數(shù)中的第一個(gè)參數(shù)設(shè)為PROCESS_TERMINATE,就可以獲取處理該進(jìn)程的句柄;

    4)利用TerminateProcess函數(shù)結(jié)束進(jìn)程,將該函數(shù)的第二個(gè)參數(shù)設(shè)為4.

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

    Java 語言中的 volatile 變量可以被看作是一種 “程度較輕的 synchronized”;與 synchronized 塊相比,volatile 變量所需的編碼較少,并且運(yùn)行時(shí)開銷也較少,但是它所能實(shí)現(xiàn)的功能也僅是 synchronized 的一部分。本文介紹了幾種有效使用 volatile 變量的模式,并強(qiáng)調(diào)了幾種不適合使用 volatile 變量的情形。

    鎖提供了兩種主要特性:互斥(mutual exclusion)可見性(visibility)。互斥即一次 只允許一個(gè)線程持有某個(gè)特定的鎖,因此可使用該特性實(shí)現(xiàn)對(duì)共享數(shù)據(jù)的協(xié)調(diào)訪問協(xié)議,這樣,一次就只有一個(gè)線程能夠使用該共享數(shù)據(jù)。可見性要更加復(fù)雜一些, 它必須確保釋放鎖之前對(duì)共享數(shù)據(jù)做出的更改對(duì)于隨后獲得該鎖的另一個(gè)線程是可見的 —— 如果沒有同步機(jī)制提供的這種可見性保證,線程看到的共享變量可能是修改前的值或不一致的值,這將引發(fā)許多嚴(yán)重問題。

    Volatile 變量

    Volatile 變量具有 synchronized 的可見性特性,但是不具備原子特性。這就是說線程能夠自動(dòng)發(fā)現(xiàn) volatile 變量的最新值。Volatile 變量可用于提供線程安全,但是只能應(yīng)用于非常有限的一組用例:多個(gè)變量之間或者某個(gè)變量的當(dāng)前值與修改后值之間沒有約束。因此,單獨(dú)使用 volatile 還不足以實(shí)現(xiàn)計(jì)數(shù)器、互斥鎖或任何具有與多個(gè)變量相關(guān)的不變式(Invariants)的類(例如 “start <=end”)。

    出于簡(jiǎn)易性或可伸縮性的考慮,您可能傾向于使用 volatile 變量而不是鎖。當(dāng)使用 volatile 變量而非鎖時(shí),某些習(xí)慣用法(idiom)更加易于編碼和閱讀。此外,volatile 變量不會(huì)像鎖那樣造成線程阻塞,因此也很少造成可伸縮性問題。在某些情況下,如果讀操作遠(yuǎn)遠(yuǎn)大于寫操作,volatile 變量還可以提供優(yōu)于鎖的性能優(yōu)勢(shì)。

    正確使用 volatile 變量的條件

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

    • 對(duì)變量的寫操作不依賴于當(dāng)前值。
    • 該變量沒有包含在具有其他變量的不變式中。

    實(shí)際上,這些條件表明,可以被寫入 volatile 變量的這些有效值獨(dú)立于任何程序的狀態(tài),包括變量的當(dāng)前狀態(tài)。

    第一個(gè)條件的限制使 volatile 變量不能用作線程安全計(jì)數(shù)器。雖然增量操作(x++)看上去類似一個(gè)單獨(dú)操作,實(shí)際上它是一個(gè)由讀取-修改-寫入操作序列組成的組合操作,必須以原子方式執(zhí)行,而 volatile 不能提供必須的原子特性。實(shí)現(xiàn)正確的操作需要使 x 的值在操作期間保持不變,而 volatile 變量無法實(shí)現(xiàn)這點(diǎn)。(然而,如果將值調(diào)整為只從單個(gè)線程寫入,那么可以忽略第一個(gè)條件。)

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


    清單 1. 非線程安全的數(shù)值范圍類
                    
    @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;
    }
    }

    這種方式限制了范圍的狀態(tài)變量,因此將 lower 和 upper 字段定義為 volatile 類型不能夠充分實(shí)現(xiàn)類的線程安全;從而仍然需要使用同步。否則,如果湊巧兩個(gè)線程在同一時(shí)間使用不一致的值執(zhí)行 setLowersetUpper 的話,則會(huì)使范圍處于不一致的狀態(tài)。例如,如果初始狀態(tài)是 (0, 5),同一時(shí)間內(nèi),線程 A 調(diào)用 setLower(4) 并且線程 B 調(diào)用 setUpper(3),顯然這兩個(gè)操作交叉存入的值是不符合條件的,那么兩個(gè)線程都會(huì)通過用于保護(hù)不變式的檢查,使得最后的范圍值是 (4, 3) —— 一個(gè)無效值。至于針對(duì)范圍的其他操作,我們需要使 setLower()setUpper() 操作原子化 —— 而將字段定義為 volatile 類型是無法實(shí)現(xiàn)這一目的的。

    性能考慮

    使用 volatile 變量的主要原因是其簡(jiǎn)易性:在某些情形下,使用 volatile 變量要比使用相應(yīng)的鎖簡(jiǎn)單得多。使用 volatile 變量次要原因是其性能:某些情況下,volatile 變量同步機(jī)制的性能要優(yōu)于鎖。

    很難做出準(zhǔn)確、全面的評(píng)價(jià),例如 “X 總是比 Y 快”,尤其是對(duì) JVM 內(nèi)在的操作而言。(例如,某些情況下 VM 也許能夠完全刪除鎖機(jī)制,這使得我們難以抽象地比較 volatilesynchronized 的開銷。)就是說,在目前大多數(shù)的處理器架構(gòu)上,volatile 讀操作開銷非常低 —— 幾乎和非 volatile 讀操作一樣。而 volatile 寫操作的開銷要比非 volatile 寫操作多很多,因?yàn)橐WC可見性需要實(shí)現(xiàn)內(nèi)存界定(Memory Fence),即便如此,volatile 的總開銷仍然要比鎖獲取低。

    volatile 操作不會(huì)像鎖一樣造成阻塞,因此,在能夠安全使用 volatile 的情況下,volatile 可以提供一些優(yōu)于鎖的可伸縮特性。如果讀操作的次數(shù)要遠(yuǎn)遠(yuǎn)超過寫操作,與鎖相比,volatile 變量通常能夠減少同步的性能開銷。

    正確使用 volatile 的模式

    很多并發(fā)性專家事實(shí)上往往引導(dǎo)用戶遠(yuǎn)離 volatile 變量,因?yàn)槭褂盟鼈円仁褂面i更加容易出錯(cuò)。然而,如果謹(jǐn)慎地遵循一些良好定義的模式,就能夠在很多場(chǎng)合內(nèi)安全地使用 volatile 變量。要始終牢記使用 volatile 的限制 —— 只有在狀態(tài)真正獨(dú)立于程序內(nèi)其他內(nèi)容時(shí)才能使用 volatile —— 這條規(guī)則能夠避免將這些模式擴(kuò)展到不安全的用例。

    模式 #1:狀態(tài)標(biāo)志

    也許實(shí)現(xiàn) volatile 變量的規(guī)范使用僅僅是使用一個(gè)布爾狀態(tài)標(biāo)志,用于指示發(fā)生了一個(gè)重要的一次性事件,例如完成初始化或請(qǐng)求停機(jī)。

    很多應(yīng)用程序包含了一種控制結(jié)構(gòu),形式為 “在還沒有準(zhǔn)備好停止程序時(shí)再執(zhí)行一些工作”,如清單 2 所示:


    清單 2. 將 volatile 變量作為狀態(tài)標(biāo)志使用
                    
    volatile boolean shutdownRequested;

    ...

    public void shutdown() { shutdownRequested = true; }

    public void doWork() {
    while (!shutdownRequested) {
    // do stuff
    }
    }

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

    這種類型的狀態(tài)標(biāo)記的一個(gè)公共特性是:通常只有一種狀態(tài)轉(zhuǎn)換;shutdownRequested 標(biāo)志從 false 轉(zhuǎn)換為 true,然后程序停止。這種模式可以擴(kuò)展到來回轉(zhuǎn)換的狀態(tài)標(biāo)志,但是只有在轉(zhuǎn)換周期不被察覺的情況下才能擴(kuò)展(從 falsetrue,再轉(zhuǎn)換到 false)。此外,還需要某些原子狀態(tài)轉(zhuǎn)換機(jī)制,例如原子變量。

    模式 #2:一次性安全發(fā)布(one-time safe publication)

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

    實(shí)現(xiàn)安全發(fā)布對(duì)象的一種技術(shù)就是將對(duì)象引用定義為 volatile 類型。清單 3 展示了一個(gè)示例,其中后臺(tái)線程在啟動(dòng)階段從數(shù)據(jù)庫加載一些數(shù)據(jù)。其他代碼在能夠利用這些數(shù)據(jù)時(shí),在使用之前將檢查這些數(shù)據(jù)是否曾經(jīng)發(fā)布過。


    清單 3. 將 volatile 變量用于一次性安全發(fā)布
                    
    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() 中的代碼在解除對(duì) theFlooble 的引用時(shí),將會(huì)得到一個(gè)不完全構(gòu)造的 Flooble

    該模式的一個(gè)必要條件是:被發(fā)布的對(duì)象必須是線程安全的,或者是有效的不可變對(duì)象(有效不可變意味著對(duì)象的狀態(tài)在發(fā)布之后永遠(yuǎn)不會(huì)被修改)。volatile 類型的引用可以確保對(duì)象的發(fā)布形式的可見性,但是如果對(duì)象的狀態(tài)在發(fā)布后將發(fā)生更改,那么就需要額外的同步。

    模式 #3:獨(dú)立觀察(independent observation)

    安全使用 volatile 的另一種簡(jiǎn)單模式是:定期 “發(fā)布” 觀察結(jié)果供程序內(nèi)部使用。例如,假設(shè)有一種環(huán)境傳感器能夠感覺環(huán)境溫度。一個(gè)后臺(tái)線程可能會(huì)每隔幾秒讀取一次該傳感器,并更新包含當(dāng)前文檔的 volatile 變量。然后,其他線程可以讀取這個(gè)變量,從而隨時(shí)能夠看到最新的溫度值。

    使用該模式的另一種應(yīng)用程序就是收集程序的統(tǒng)計(jì)信息。清單 4 展示了身份驗(yàn)證機(jī)制如何記憶最近一次登錄的用戶的名字。將反復(fù)使用 lastUser 引用來發(fā)布值,以供程序的其他部分使用。


    清單 4. 將 volatile 變量用于多個(gè)獨(dú)立觀察結(jié)果的發(fā)布
                    
    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;
    }
    }

    該模式是前面模式的擴(kuò)展;將某個(gè)值發(fā)布以在程序內(nèi)的其他地方使用,但是與一次性事件的發(fā)布不同,這是一系列獨(dú)立事件。這個(gè)模式要求被發(fā)布的值是有效不可變的 —— 即值的狀態(tài)在發(fā)布后不會(huì)更改。使用該值的代碼需要清楚該值可能隨時(shí)發(fā)生變化。

    模式 #4:“volatile bean” 模式

    volatile bean 模式適用于將 JavaBeans 作為“榮譽(yù)結(jié)構(gòu)”使用的框架。在 volatile bean 模式中,JavaBean 被用作一組具有 getter 和/或 setter 方法 的獨(dú)立屬性的容器。volatile bean 模式的基本原理是:很多框架為易變數(shù)據(jù)的持有者(例如 HttpSession)提供了容器,但是放入這些容器中的對(duì)象必須是線程安全的。

    在 volatile bean 模式中,JavaBean 的所有數(shù)據(jù)成員都是 volatile 類型的,并且 getter 和 setter 方法必須非常普通 —— 除了獲取或設(shè)置相應(yīng)的屬性外,不能包含任何邏輯。此外,對(duì)于對(duì)象引用的數(shù)據(jù)成員,引用的對(duì)象必須是有效不可變的。(這將禁止具有數(shù)組值的屬性,因?yàn)楫?dāng)數(shù)組 引用被聲明為 volatile 時(shí),只有引用而不是數(shù)組本身具有 volatile 語義)。對(duì)于任何 volatile 變量,不變式或約束都不能包含 JavaBean 屬性。清單 5 中的示例展示了遵守 volatile bean 模式的 JavaBean:


    清單 5. 遵守 volatile bean 模式的 Person 對(duì)象
                    
    @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 的高級(jí)模式

    前面幾節(jié)介紹的模式涵蓋了大部分的基本用例,在這些模式中使用 volatile 非常有用并且簡(jiǎn)單。這一節(jié)將介紹一種更加高級(jí)的模式,在該模式中,volatile 將提供性能或可伸縮性優(yōu)勢(shì)。

    volatile 應(yīng)用的的高級(jí)模式非常脆弱。因此,必須對(duì)假設(shè)的條件仔細(xì)證明,并且這些模式被嚴(yán)格地封裝了起來,因?yàn)榧词狗浅P〉母囊矔?huì)損壞您的代碼!同樣,使用更高級(jí) 的 volatile 用例的原因是它能夠提升性能,確保在開始應(yīng)用高級(jí)模式之前,真正確定需要實(shí)現(xiàn)這種性能獲益。需要對(duì)這些模式進(jìn)行權(quán)衡,放棄可讀性或可維護(hù)性來換取可能的性 能收益 —— 如果您不需要提升性能(或者不能夠通過一個(gè)嚴(yán)格的測(cè)試程序證明您需要它),那么這很可能是一次糟糕的交易,因?yàn)槟芸赡軙?huì)得不償失,換來的東西要比放棄的 東西價(jià)值更低。

    模式 #5:開銷較低的讀-寫鎖策略

    目前為止,您應(yīng)該了解了 volatile 的功能還不足以實(shí)現(xiàn)計(jì)數(shù)器。因?yàn)?++x 實(shí)際上是三種操作(讀、添加、存儲(chǔ))的簡(jiǎn)單組合,如果多個(gè)線程湊巧試圖同時(shí)對(duì) volatile 計(jì)數(shù)器執(zhí)行增量操作,那么它的更新值有可能會(huì)丟失。

    然而,如果讀操作遠(yuǎn)遠(yuǎn)超過寫操作,您可以結(jié)合使用內(nèi)部鎖和 volatile 變量來減少公共代碼路徑的開銷。清單 6 中顯示的線程安全的計(jì)數(shù)器使用 synchronized 確保增量操作是原子的,并使用 volatile 保證當(dāng)前結(jié)果的可見性。如果更新不頻繁的話,該方法可實(shí)現(xiàn)更好的性能,因?yàn)樽x路徑的開銷僅僅涉及 volatile 讀操作,這通常要優(yōu)于一個(gè)無競(jìng)爭(zhēng)的鎖獲取的開銷。


    清單 6. 結(jié)合使用 volatile 和 synchronized 實(shí)現(xiàn) “開銷較低的讀-寫鎖”
                    
    @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++;
    }
    }

    之所以將這種技術(shù)稱之為 “開銷較低的讀-寫鎖” 是因?yàn)槟褂昧瞬煌耐綑C(jī)制進(jìn)行讀寫操作。因?yàn)楸纠械膶懖僮鬟`反了使用 volatile 的第一個(gè)條件,因此不能使用 volatile 安全地實(shí)現(xiàn)計(jì)數(shù)器 —— 您必須使用鎖。然而,您可以在讀操作中使用 volatile 確保當(dāng)前值的可見性, 因此可以使用鎖進(jìn)行所有變化的操作,使用 volatile 進(jìn)行只讀操作。其中,鎖一次只允許一個(gè)線程訪問值,volatile 允許多個(gè)線程執(zhí)行讀操作,因此當(dāng)使用 volatile 保證讀代碼路徑時(shí),要比使用鎖執(zhí)行全部代碼路徑獲得更高的共享度 —— 就像讀-寫操作一樣。然而,要隨時(shí)牢記這種模式的弱點(diǎn):如果超越了該模式的最基本應(yīng)用,結(jié)合這兩個(gè)競(jìng)爭(zhēng)的同步機(jī)制將變得非常困難。

    結(jié)束語

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



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

    posted @ 2010-12-20 14:02 temper 閱讀(243) | 評(píng)論 (0)編輯 收藏
    java調(diào)用bat,用xcopy拷貝系統(tǒng)日志到指定目錄。如果jdk版本是32位,因?yàn)槲④涀隽讼到y(tǒng)重定向,不能拷貝過去。
    將%WinDir%\System32\Winevt\Logs\Application.evtx修改為%WinDir%\Sysnative\Winevt\Logs\Application.evtx,即可實(shí)現(xiàn)。
    參考資料:http://support.microsoft.com/kb/942589/

    posted @ 2010-07-26 13:09 temper 閱讀(1023) | 評(píng)論 (0)編輯 收藏
    http://blog.csdn.net/watchnight/archive/2010/01/26/5258532.aspx

    沒有一個(gè)平臺(tái)獨(dú)立的方法能夠在所有的JVM上實(shí)現(xiàn)。一個(gè)最簡(jiǎn)單、最接近取得PID的辦法是使用:

    ManagementFactory.getRuntimeMXBean().getName() 。

    取得到的字符竄的格式為[PROCESS_ID]@[MACHINE_NAME],通過解析這個(gè)字符串就可以得到j(luò)ava進(jìn)程的PID。

    在以下平臺(tái)上測(cè)試通過:

    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) | 評(píng)論 (0)編輯 收藏
    將jvm.dll拷貝到JavaService.exe所在目錄(也可以通過設(shè)置path實(shí)現(xiàn))
    參照:http://forge.ow2.org/forum/forum.php?thread_id=2330&forum_id=625

    ps:推薦通過設(shè)置path來實(shí)現(xiàn),畢竟這樣對(duì)用戶和空間需求改動(dòng)最小。
    參照:http://www.tmro.net/2008/05/jboss-service-on-windows-server-2003/
    posted @ 2010-06-25 14:28 temper 閱讀(383) | 評(píng)論 (0)編輯 收藏

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


    一、相關(guān)概念


    基本回收算法

    1. 引用計(jì)數(shù)(Reference Counting)
      比較古老的回收算法。原理是此對(duì)象有一個(gè)引用,即 增加一個(gè)計(jì)數(shù),刪除一個(gè)引用則減少一個(gè)計(jì)數(shù)。垃圾回收時(shí),只用收集計(jì)數(shù)為0的對(duì)象。此算法最致命的是無法處理循環(huán)引用的問題。
    2. 標(biāo)記-清除(Mark-Sweep)
      此算法執(zhí)行分兩階段。第一階段從引用根節(jié)點(diǎn)開始標(biāo)記所 有被引用的對(duì)象,第二階段遍歷整個(gè)堆,把未標(biāo)記的對(duì)象清除。此算法需要暫停整個(gè)應(yīng)用,同時(shí),會(huì)產(chǎn)生內(nèi)存碎片。
    3. 復(fù)制(Copying)
      此算法把內(nèi)存空間劃為兩個(gè)相等的區(qū)域,每次只使用其中一個(gè)區(qū)域。垃 圾回收時(shí),遍歷當(dāng)前使用區(qū)域,把正在使用中的對(duì)象復(fù)制到另外一個(gè)區(qū)域中。次算法每次只處理正在使用中的對(duì)象,因此復(fù)制成本比較小,同時(shí)復(fù)制過去以后還能進(jìn) 行相應(yīng)的內(nèi)存整理,不過出現(xiàn)“碎片”問題。當(dāng)然,此算法的缺點(diǎn)也是很明顯的,就是需要兩倍內(nèi)存空間。
    4. 標(biāo)記-整理(Mark-Compact)
      此算法結(jié)合了“標(biāo)記-清除”和“復(fù)制”兩個(gè)算法的 優(yōu)點(diǎn)。也是分兩階段,第一階段從根節(jié)點(diǎn)開始標(biāo)記所有被引用對(duì)象,第二階段遍歷整個(gè)堆,把清除未標(biāo)記對(duì)象并且把存活對(duì)象“壓縮”到堆的其中一塊,按順序排 放。此算法避免了“標(biāo)記-清除”的碎片問題,同時(shí)也避免了“復(fù)制”算法的空間問題。
    5. 增量收集(Incremental Collecting)
      實(shí)施垃圾回收算法,即:在應(yīng)用 進(jìn)行的同時(shí)進(jìn)行垃圾回收。不知道什么原因JDK5.0中的收集器沒有使用這種算法的。
    6. 分代(Generational Collecting)
      基于對(duì)對(duì)象生命周期分析后得出的 垃圾回收算法。把對(duì)象分為年青代、年老代、持久代,對(duì)不同生命周期的對(duì)象使用不同的算法(上述方式中的一個(gè))進(jìn)行回收。現(xiàn)在的垃圾回收器(從 J2SE1.2開始)都是使用此算法的。

    分代垃圾回收詳述


    如上圖所示,為Java堆中的各代分布。

    1. Young(年輕代)
      年輕代分三個(gè)區(qū)。一個(gè)Eden區(qū),兩個(gè)Survivor區(qū)。大部分對(duì)象在 Eden區(qū)中生成。當(dāng)Eden區(qū)滿時(shí),還存活的對(duì)象將被復(fù)制到Survivor區(qū)(兩個(gè)中的一個(gè)),當(dāng)這個(gè)Survivor區(qū)滿時(shí),此區(qū)的存活對(duì)象將被復(fù) 制到另外一個(gè)Survivor區(qū),當(dāng)這個(gè)Survivor去也滿了的時(shí)候,從第一個(gè)Survivor區(qū)復(fù)制過來的并且此時(shí)還存活的對(duì)象,將被復(fù)制“年老區(qū) (Tenured)”。需要注意,Survivor的兩個(gè)區(qū)是對(duì)稱的,沒先后關(guān)系,所以同一個(gè)區(qū)中可能同時(shí)存在從Eden復(fù)制過來 對(duì)象,和從前一個(gè)Survivor復(fù)制過來的對(duì)象,而復(fù)制到年老區(qū)的只有從第一個(gè)Survivor去過來的對(duì)象。而且,Survivor區(qū)總有一個(gè)是空 的。
    2. Tenured(年老代)
      年老代存放從年輕代存活的對(duì)象。一般來說年老代存放的都是生命期 較長的對(duì)象。
    3. Perm(持久代)
      用于存放靜態(tài)文件,如今Java類、方法等。持久代對(duì)垃圾回收沒有顯著 影響,但是有些應(yīng)用可能動(dòng)態(tài)生成或者調(diào)用一些class,例如Hibernate等,在這種時(shí)候需要設(shè)置一個(gè)比較大的持久代空間來存放這些運(yùn)行過程中新增 的類。持久代大小通過-XX:MaxPermSize=<N>進(jìn)行設(shè)置。

    GC類型
    GC有兩種類型:Scavenge GC和Full GC
    1. Scavenge GC
      一般情況下,當(dāng)新對(duì)象生成,并且在Eden申請(qǐng)空間失敗時(shí),就好觸發(fā)Scavenge GC,堆Eden區(qū)域進(jìn)行GC,清除非存活對(duì)象,并且把尚且存活的對(duì)象移動(dòng)到Survivor區(qū)。然后整理Survivor的兩個(gè)區(qū)。
    2. Full GC
      對(duì)整個(gè)堆進(jìn)行整理,包括Young、Tenured和Perm。Full GC比Scavenge GC要慢,因此應(yīng)該盡可能減少Full GC。有如下原因可能導(dǎo)致Full GC:
      • Tenured被寫滿
      • Perm域被寫滿
      • System.gc()被顯示調(diào)用
      • 上一次GC之后Heap的各域分配策略動(dòng)態(tài)變化


    分代垃圾回收過程演示




    二、垃圾回收器


    目前的收集器主要有三種:串行 收集器、并行收集器、并發(fā)收集器

    1. 串行收集器

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

    三、常見配置舉例
    1. 堆大小設(shè)置
      JVM 中最大堆大小有三方面限制:相關(guān)操作系統(tǒng)的數(shù)據(jù)模型(32-bt還是64-bit)限制;系統(tǒng)的可用虛擬內(nèi)存限制;系統(tǒng)的可用物理內(nèi)存限制。32位系統(tǒng) 下,一般限制在1.5G~2G;64為操作系統(tǒng)對(duì)內(nèi)存無限制。我在Windows Server 2003 系統(tǒng),3.5G物理內(nèi)存,JDK5.0下測(cè)試,最大可設(shè)置為1478m。
      典型設(shè)置:
      • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k
        -Xmx3550m: 設(shè)置JVM最大可用內(nèi)存為3550M。
        -Xms3550m: 設(shè)置JVM促使內(nèi)存為3550m。此值可以設(shè)置與-Xmx相同,以避免每次垃圾回收完成后JVM重新分配內(nèi)存。
        -Xmn2g:設(shè)置年輕代大小為2G。整個(gè)堆大小=年輕代大小 + 年老代大小 + 持久代大小。持久代一般固定大小為 64m,所以增大年輕代后,將會(huì)減小年老代大小。此值對(duì)系統(tǒng)性能影響較大,Sun官方推薦配置為整個(gè)堆的3/8。
        -Xss128k: 設(shè)置每個(gè)線程的堆棧大小。JDK5.0以后每個(gè)線程堆棧大小為1M,以前每個(gè)線程堆棧大小為256K。更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行調(diào)整。在相同物理內(nèi) 存下,減小這個(gè)值能生成更多的線程。但是操作系統(tǒng)對(duì)一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗(yàn)值在3000~5000左右。
      • java -Xmx3550m -Xms3550m -Xss128k -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX:MaxPermSize=16m -XX:MaxTenuringThreshold=0
        -XX:NewRatio=4: 設(shè)置年輕代(包括Eden和兩個(gè)Survivor區(qū))與年老代的比值(除去持久代)。設(shè)置為4,則年輕代與年老代所占比值為1:4,年輕代占整個(gè)堆棧的 1/5
        -XX:SurvivorRatio=4:設(shè)置年輕代中 Eden區(qū)與Survivor區(qū)的大小比值。設(shè)置為4,則兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:4,一個(gè)Survivor區(qū)占整個(gè)年輕代的 1/6
        -XX:MaxPermSize=16m:設(shè)置持久代大小為16m。
        -XX:MaxTenuringThreshold=0: 設(shè)置垃圾最大年齡。如果設(shè)置為0的話,則年輕代對(duì)象不經(jīng)過Survivor區(qū),直接進(jìn)入年 老代。對(duì)于年老代比較多的應(yīng)用,可以提高效率。如果將此 值設(shè)置為一個(gè)較大值,則年輕代對(duì)象會(huì)在Survivor區(qū)進(jìn)行多次復(fù)制,這樣可以增加對(duì)象再年輕代的存活時(shí)間,增加在年 輕代即被回收的概論。
    2. 回收器選擇
      JVM給了三種選擇:串行收集器、并行收集器、并發(fā)收集器, 但是串行收集器只適用于小數(shù)據(jù)量的情況,所以這里的選擇主要針對(duì)并行收集器和并發(fā)收集器。默認(rèn)情況下,JDK5.0以前都是使用串行收集器,如果想使用其 他收集器需要在啟動(dòng)時(shí)加入相應(yīng)參數(shù)。JDK5.0以后,JVM會(huì)根據(jù)當(dāng)前系統(tǒng)配置進(jìn)行判斷。
      1. 吞吐量優(yōu)先的并行收集器
        如上文所述,并行收集器主要以到達(dá)一定的吞吐量為目標(biāo),適用于科學(xué)技術(shù)和后臺(tái) 處理等。
        典型配置
        • java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
          -XX:+UseParallelGC: 選擇垃圾收集器為并行收集器。此配置僅對(duì)年輕代有效。即上述配置下,年輕代使用并發(fā)收集, 而年老代仍舊使用串行收集。
          -XX:ParallelGCThreads=20: 配置并行收集器的線程數(shù),即:同時(shí)多少個(gè)線程一起進(jìn)行垃圾回收。此值最好配置與處理器數(shù)目相等。
        • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
          -XX:+UseParallelOldGC: 配置年老代垃圾收集方式為并行收集。JDK6.0支持對(duì)年老代并行收集。
        • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100
          -XX:MaxGCPauseMillis=100:設(shè) 置每次年輕代垃圾回收的最長時(shí)間,如果無法滿足此時(shí)間,JVM會(huì)自動(dòng)調(diào)整年輕代大小,以滿足此值。
        • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC  -XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy
          -XX:+UseAdaptiveSizePolicy
          : 設(shè)置此選項(xiàng)后,并行收集器會(huì)自動(dòng)選擇年輕代區(qū)大小和相應(yīng)的Survivor區(qū)比例,以達(dá)到目標(biāo)系統(tǒng)規(guī)定的最低相應(yīng)時(shí)間或者收集頻率等,此值建議使用并行收 集器時(shí),一直打開。
      2. 響應(yīng)時(shí)間優(yōu)先的并發(fā)收集器
        如上文所述,并發(fā)收集器主要是保證系統(tǒng)的響應(yīng)時(shí)間,減少垃圾收集 時(shí)的停頓時(shí)間。適用于應(yīng)用服務(wù)器、電信領(lǐng)域等。
        典型配置
        • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
          -XX:+UseConcMarkSweepGC: 設(shè)置年老代為并發(fā)收集。測(cè)試中配置這個(gè)以后,-XX:NewRatio=4的配置失效了,原因不明。所以,此時(shí)年輕代大小最好 用-Xmn設(shè)置。
          -XX:+UseParNewGC:設(shè) 置年輕代為并行收集。可與CMS收集同時(shí)使用。JDK5.0以上,JVM會(huì)根據(jù)系統(tǒng)配置自行設(shè)置,所以無需再設(shè)置此值。
        • java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
          -XX:CMSFullGCsBeforeCompaction: 由于并發(fā)收集器不對(duì)內(nèi)存空間進(jìn)行壓縮、整理,所以運(yùn)行一段時(shí)間以后會(huì)產(chǎn)生“碎片”,使得運(yùn)行效率降低。此值設(shè)置運(yùn)行多少次GC以后對(duì)內(nèi)存空間進(jìn)行壓縮、整 理。
          -XX:+UseCMSCompactAtFullCollection:打開對(duì)年 老代的壓縮。可能會(huì)影響性能,但是可以消除碎片
    3. 輔助信息
      JVM提供了大量命令行參數(shù),打印信息,供調(diào)試使用。主要有以下一些:
      • -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可與上面兩個(gè)混合使用
        輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]
      • -XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收 前,程序未中斷的執(zhí)行時(shí)間。可與上面混合使用
        輸出形式:Application time: 0.5291524 seconds
      • -XX:+PrintGCApplicationStoppedTime:打印垃圾回收期間程序暫 停的時(shí)間。可與上面混合使用
        輸出形式:Total time for which application threads were stopped: 0.0468229 seconds
      • -XX:PrintHeapAtGC:打印GC前后的詳細(xì)堆棧信息
        輸出形式:
        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:與上面幾個(gè)配合使用,把相關(guān)日志信息記錄到文件以便分析。
    4. 常見配置匯總
      1. 堆設(shè)置
        • -Xms:初始堆大小
        • -Xmx:最大堆大小
        • -XX:NewSize=n:設(shè)置年輕代大小
        • -XX:NewRatio=n:設(shè)置年輕代和年老代的比值。如:為3,表示年輕代與年老代比值為 1:3,年輕代占整個(gè)年輕代年老代和的1/4
        • -XX:SurvivorRatio=n:年輕代中Eden區(qū)與兩個(gè)Survivor區(qū)的比值。注 意Survivor區(qū)有兩個(gè)。如:3,表示Eden:Survivor=3:2,一個(gè)Survivor區(qū)占整個(gè)年輕代的1/5
        • -XX:MaxPermSize=n:設(shè)置持久代大小
      2. 收集器設(shè)置
        • -XX:+UseSerialGC:設(shè)置串行收集器
        • -XX:+UseParallelGC:設(shè)置并行收集器
        • -XX:+UseParalledlOldGC:設(shè)置并行年老代收集器
        • -XX:+UseConcMarkSweepGC:設(shè)置并發(fā)收集器
      3. 垃圾回收統(tǒng)計(jì)信息
        • -XX:+PrintGC
        • -XX:+PrintGCDetails
        • -XX:+PrintGCTimeStamps
        • -Xloggc:filename
      4. 并行收集器設(shè)置
        • -XX:ParallelGCThreads=n:設(shè)置并行收集器收集時(shí)使用的CPU數(shù)。并行收集線程數(shù)。
        • -XX:MaxGCPauseMillis=n:設(shè)置并行收集最大暫停時(shí)間
        • -XX:GCTimeRatio=n:設(shè)置垃圾回收時(shí)間占程序運(yùn)行時(shí)間的百分比。公式為 1/(1+n)
      5. 并發(fā)收集器設(shè)置
        • -XX:+CMSIncrementalMode:設(shè)置為增量模式。適用于單CPU情況。
        • -XX:ParallelGCThreads=n:設(shè)置并發(fā)收集器年輕代收集方式為并行收集時(shí),使 用的CPU數(shù)。并行收集線程數(shù)。

    四、 調(diào)優(yōu)總結(jié)
    1. 年輕代大小選擇
      • 響應(yīng)時(shí)間優(yōu)先的應(yīng)用盡可能設(shè)大,直到接近系 統(tǒng)的最低響應(yīng)時(shí)間限制(根據(jù)實(shí)際情況選擇)。在此種情況下,年輕代收集發(fā)生的頻率也是最小的。同時(shí),減少到達(dá)年老代的對(duì) 象。
      • 吞吐量優(yōu)先的應(yīng)用:盡可能的設(shè)置大,可能到達(dá)Gbit的程度。因?yàn)閷?duì)響應(yīng)時(shí)間沒有要求,垃圾收集可 以并行進(jìn)行,一般適合8CPU以上的應(yīng)用。
    2. 年老代大小選擇
      • 響應(yīng)時(shí)間優(yōu)先的應(yīng)用:年老代使用并發(fā)收集器,所以其大小需要小心設(shè)置,一般要考慮并發(fā)會(huì)話率會(huì) 話持續(xù)時(shí)間等一些參數(shù)。如果堆設(shè)置小了,可以會(huì)造成內(nèi)存碎片、高回收頻率以及應(yīng)用暫停而使用傳統(tǒng)的標(biāo)記清除方式;如果堆大了,則需要較 長的收集時(shí)間。最優(yōu)化的方案,一般需要參考以下數(shù)據(jù)獲得:
        • 并發(fā)垃圾收集信息
        • 持久代并發(fā)收集次數(shù)
        • 傳統(tǒng)GC信息
        • 花在年輕代和年老代回收上的時(shí)間比例
        減少年輕代和年老代花費(fèi)的時(shí)間,一般會(huì)提高應(yīng)用的效率
      • 吞吐量優(yōu)先的應(yīng)用:一般吞吐量優(yōu)先的應(yīng)用都有一個(gè)很大的年輕代和一個(gè)較小的年老代。原因是,這樣可 以盡可能回收掉大部分短期對(duì)象,減少中期的對(duì)象,而年老代盡存放長期存活對(duì)象。
    3. 較小堆引起的碎片問題
      因?yàn)槟昀洗牟l(fā)收集器使用標(biāo)記、清除算法,所以不會(huì)對(duì)堆進(jìn)行壓縮。 當(dāng)收集器回收時(shí),他會(huì)把相鄰的空間進(jìn)行合并,這樣可以分配給較大的對(duì)象。但是,當(dāng)堆空間較小時(shí),運(yùn)行一段時(shí)間以后,就會(huì)出現(xiàn)“碎片”,如果并發(fā)收集器找不 到足夠的空間,那么并發(fā)收集器將會(huì)停止,然后使用傳統(tǒng)的標(biāo)記、清除方式進(jìn)行回收。如果出現(xiàn)“碎片”,可能需要進(jìn)行如下配置:
      • -XX:+UseCMSCompactAtFullCollection:使用并發(fā)收集器時(shí),開啟對(duì)年老代的壓縮。
      • -XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這里設(shè)置多少次Full GC后,對(duì)年老代進(jìn)行壓縮
    posted @ 2010-06-25 14:21 temper 閱讀(164) | 評(píng)論 (0)編輯 收藏
    http://blog.csdn.net/ai_33/archive/2008/06/10/2529096.aspx

    關(guān)于中文文件下載的問題,網(wǎng)上的咨詢和答疑已經(jīng)很多,我原來處理下載的代碼如下:
        
        response.setHeader("Content-Disposition", "attachment; filename=" + java.net.URLEncoder.encode(fileName, "UTF-8"));
     下載的程序里有了這句,一般在IE6的下載提示框上將正確顯示文件的名字,無論是簡(jiǎn)體中文,還是日文。不過當(dāng)時(shí)確實(shí)沒有仔細(xì)測(cè)試文件名很長的中文文件名。先如今經(jīng)過仔細(xì)測(cè)試,發(fā)現(xiàn)文字只要超過17個(gè)字,就不能下載了。經(jīng)過好一番google和反復(fù)測(cè)試,總算對(duì)這個(gè)問題有了系統(tǒng)的認(rèn)識(shí),分列如下:

        . 通過我原來的方式,也就是先用URLEncoder編碼,當(dāng)中文文字超過17個(gè)時(shí),IE6 無法下載文件。這是IE的bug,參見微軟的知識(shí)庫文章 KB816868 。原因可能是因?yàn)閕e在處理 Response Header 的時(shí)候,對(duì)header的長度限制在150字節(jié)左右。而一個(gè)漢字編碼成UTF-8是9個(gè)字節(jié),那么17個(gè)字便是153個(gè)字節(jié),所以便會(huì)報(bào)錯(cuò)。微軟提供了一個(gè)補(bǔ)丁,可以從 這里 下載。這個(gè)補(bǔ)丁需要先安裝ie6 sp1。因?yàn)槲移綍r(shí)勤打補(bǔ)丁,我的IE6版本號(hào)是 6.0.2800.1106.xpsp2_xxxxx。所以我可能已經(jīng)安裝過了補(bǔ)丁,從而可以下載,但仍然出現(xiàn)文件名被截?cái)嗟默F(xiàn)象。微軟讓我們等待IE下一個(gè)service pack的發(fā)布。我今天也上網(wǎng)看到了好消息,迫于firefox的壓力,IE7可能在年中發(fā)布。另外,F(xiàn)irefox 不支持這樣的方式,將把編碼后的%xx%xx直接作為文件名顯示。


        . 我嘗試使用 javamail 的MimeUtility.encode()方法來編碼文件名,也就是編碼成 =?gb2312?B?xxxxxxxx?= 這樣的形式,并從 RFC1522 中找到對(duì)應(yīng)的標(biāo)準(zhǔn)支持。不過很遺憾,IE6并不支持這一個(gè)標(biāo)準(zhǔn)。我試了一下,F(xiàn)irefox是支持的。

        . 按網(wǎng)上很多人提供的解決方案:將文件名編碼成ISO8859-1似乎是有效的解決方案,代碼如下:
        
        response.setHeader( "Content-Disposition", "attachment;filename="  + new String( fileName.getBytes("gb2312"), "ISO8859-1" ) );
        
        在確保附件文件名都是簡(jiǎn)體中文字的情況下,那么這個(gè)辦法確實(shí)是最有效的,不用讓客戶逐個(gè)的升級(jí)IE。如果臺(tái)灣同胞用,把gb2312改成big5就行。但現(xiàn)在的系統(tǒng)通常都加入了國際化的支持,普遍使用UTF-8。如果文件名中又有簡(jiǎn)體中文字,又有繁體中文,還有日文。那么亂碼便產(chǎn)生了。另外,在我的電腦上Firefox(v1.0-en)下載也是亂碼。

        折中考慮,我結(jié)合了一、三的方式,代碼片斷如下:

            String fileName = URLEncoder.encode(atta.getFileName(), "UTF-8");
            /*
             * see http://support.microsoft.com/default.aspx?kbid=816868
             */
            if (fileName.length() > 150) {
                String guessCharset = xxxx /*根據(jù)request的locale 得出可能的編碼,中文操作系統(tǒng)通常是gb2312*/
                fileName = new String(atta.getFileName().getBytes(guessCharset), "ISO8859-1");
            }
            response.setHeader("Content-Disposition", "attachment; filename=" + fileName);
            
        暫且不考慮 Firefox 是因?yàn)樗壳八坪踹€沒有有力侵食到IE的企業(yè)用戶市場(chǎng)。影響客戶買單的常常是進(jìn)度,而不是兼容度。
    posted @ 2009-05-08 17:30 temper 閱讀(1359) | 評(píng)論 (0)編輯 收藏
    曾經(jīng)在系統(tǒng)中使用了一個(gè)從網(wǎng)上弄來的可編輯select,根據(jù)需要做了一些修改,在ie6下面運(yùn)行正常。昨晚突然收到領(lǐng)導(dǎo)郵件說不好用。了解完才知道是在ie8下面出問題,每次把鼠標(biāo)放到那個(gè)黃色的按鈕上面,都會(huì)出現(xiàn)一個(gè)action.do的提示。
    此button對(duì)應(yīng)的js是:
    esHTML='<div id='+this.divname+'>'
             
    +'<table id='+this.tablename+' cellpadding=0 cellspacing=0 class=select><tr><td bgcolor=#FFFFFF>'
             
    +'<input type=text class=selecttext size="'+size+'" name='+name+' value="'+defaulttext+'" '+readonly+'><td><button class=selectbutton id='+this.buttonname+'>6</td></tr></table>'
             
    +'</div>'
    ps:俺們以前一直只支持ie6,這就是不做網(wǎng)站的好處。
    趕緊下載一個(gè)ie8裝上,確認(rèn)此問題,然后滿世界的找資料。說實(shí)話,也沒找到。
    后來一氣之下試驗(yàn)了一下另外一種寫法,居然好用了,希望牛人給點(diǎn)解釋。
    esHTML='<div id='+this.divname+'>'
             
    +'<table id='+this.tablename+' cellpadding=0 cellspacing=0 class=select><tr><td bgcolor=#FFFFFF>'
             
    +'<input type=text class=selecttext size="'+size+'" name='+name+' value="'+defaulttext+'" '+readonly+'><td><input type="button" class="selectbutton" id='+this.buttonname+' value="6"/></td></tr></table>'
             
    +'</div>'
    看來要趕緊學(xué)習(xí)了,不然ie9出來我就得去要飯了。
    posted @ 2009-04-03 15:23 temper 閱讀(114) | 評(píng)論 (0)編輯 收藏
    Hi   TOM,  
      I   have   a   problem   with   ref   cursors.I'll   try   to   explain   it(sorry   if   my   english   is    
      not   very   good).  
      I   have   2   databases   and   i   want   to   return   values   from   one   DBto   the   other.  
      In   the   DB   that   i   want   to   recieve   the   data   i   have   the   call(with   a   procedure)   and      
      i   create   a   variable    
      wich   the   type   is   REF   CURSOR   from   the   second   DB.   In   example:  
      --the   variable    
      vResultCursor   user_DB2.pk_k1.vSqlCursorD@DB2;    
      --where   pk1   is   a   package   in   which   i   declare   the   REF   CURSOR   variable  
      ..  
      --The   call  
      user_DB2.pk_k1.P_1@DB2(vResultCursor);  
      --where   P1   is   the   procedure   in   wich   i   open   the   cursor   and    
      after   that   i   want   to   work   with   this   cursor  
       
      loop            
      --vx   is   varchar2              
                      FETCH   vResultCursor   INTO   vx;  
                            EXIT   WHEN   vResultCursor%NOTFOUND;  
                            insert   into   tbl_probe   values   (sysdate,'vx',vx);              
                          commit;                          
                 
      end   loop;  
      close     vResultCursor;  
       
      In   the   first   DB   i   have   in   PK_K1   the   declaration   of   the   ref   cursor,   and   the    
      procedure   wich   open   the   dinamic  
        cursor:  
      CREATE     OR   REPLACE   PACKAGE   PK_K1   IS    
      TYPE   vSqlCursorD   IS   REF   CURSOR;  
      PROCEDURE   P_RESOLVECURSOR   (vSQLCURSOR   OUT   vSqlCursorD);  
      END   PK_K1;  
       
      CREATE   OR   REPLACE   PACKAGE   BODY   PK_K1   IS  
       
      PROCEDURE   P_RESOLVECURSOR   (vSQLCURSOR   OUT   vSqlCursorD)   IS  
      vSqlCursortxt   VARCHAR2(4096);  
      BEGIN  
      vSqlCursortxt:=   'SELECT   *   FROM   DUAL';  
      OPEN   vSQLCURSOR   FOR   vSqlCursortxt;  
      EXCEPTION  
                        WHEN   OTHERS   THEN  
                                    IF   (vSQLCURSOR%ISOPEN)   THEN  
                                            CLOSE   vSQLCURSOR;  
                                  END   IF;  
      END;    
      END   PK_K1;  
      The   problem   that   i   have   is,   that   if   i   make   a   procedure   in   the   package   PK_K1   and    
      i   call   the   procedure   P_RESOLVECURSOR  
      it   works,   but   when   i   call   from   the   other   DB   it   doesnt   work.   The   error   is   ERROR    
      ORA-01001   when   whe   make   the   FETCH  
      I   gave   the   EXECUTE   grant   from   one   DB   to   the   OTHER  
      GRANT   EXECUTE   ON   PK_K1   TO   USERDB1;  
      could   u   help   me?  
      Thanks    
         
       
       
      Followup:  
       
      ref   cursors   cannot   be   used   over   a   dblink   like   that.  
       
       
      http://download-east.oracle.com/docs/cd/B19306_01/appdev.102/b14261/sqloperations.htm#sthref1448  
       
      ....  
      Note:  
       
              *     Using   a   REF   CURSOR   variable   in   a   server-to-server   RPC   results   in   an    
      error.   However,   a   REF   CURSOR   variable   is   permitted   in   a   server-to-server   RPC   if    
      the   remote   database   is   a   non-Oracle   database   accessed   through   a   Procedural    
      Gateway.  
              *     LOB   parameters   are   not   permitted   in   a   server-to-server   RPC.  
       
      .....    
       
      Passing   a   cursor   from   one   DB   to   the   other     March   23,   2006  
      Reviewer:     Jorge     from   Spain  
       
      Thank   for   the   explanation,   we   solve   the   problem   opening   and   closing   the   cursor    
      in   one   DB   and   passig   the   data   to   the   other   server   in   an   TABLE   Object   by   means   of    
      a   function.  
      Thanks   a   lot     

      ==========================================================
    看來這幾天的努力白費(fèi)了,氣憤啊
    posted @ 2009-03-30 16:58 temper 閱讀(146) | 評(píng)論 (0)編輯 收藏
    創(chuàng)建另一個(gè)數(shù)據(jù)庫的連接
    CREATE [PUBLIC] DATABASE LINK dblink
        [CONNECT TO user IDENTIFIED BY password]
        [USING 'connect_string']



    部署新版本
    java.util.zip.ZipException: invalid entry CRC (expected 0x0 but got 0xab633fa2)
     at java.util.zip.ZipInputStream.read(ZipInputStream.java:164)
     at java.util.jar.JarInputStream.read(JarInputStream.java:171)
     at java.io.BufferedInputStream.read1(BufferedInputStream.java:254)
     at java.io.BufferedInputStream.read(BufferedInputStream.java:313)
     at java.util.jar.JarInputStream.getBytes(JarInputStream.java:88)
     at java.util.jar.JarInputStream.<init>(JarInputStream.java:65)
     at java.util.jar.JarInputStream.<init>(JarInputStream.java:43)
    原因:jdk版本不對(duì)
    posted @ 2009-03-27 13:22 temper 閱讀(179) | 評(píng)論 (0)編輯 收藏
    主站蜘蛛池模板: 久久精品国产影库免费看| 最近国语视频在线观看免费播放 | 好猛好深好爽好硬免费视频| 亚洲AV无码成人精品区在线观看| 成年午夜视频免费观看视频| 亚美影视免费在线观看| 亚洲国产精品99久久久久久| 亚洲色图在线观看| 亚洲国产精品丝袜在线观看| 最近免费字幕中文大全视频| 美国毛片亚洲社区在线观看| 在线观看永久免费视频网站| 免费无码又爽又刺激一高潮| 亚洲成av人无码亚洲成av人| 亚洲AV永久无码天堂影院| 国产精品亚洲二区在线观看 | 亚洲男人天堂2020| 最近最好的中文字幕2019免费| 在线永久免费的视频草莓| 美女18一级毛片免费看| 亚洲日本va在线观看| 亚洲av中文无码乱人伦在线咪咕| 亚洲电影一区二区| 亚洲黄色片在线观看| 亚洲国产中文字幕在线观看| 免费在线黄色网址| 国产极品粉嫩泬免费观看| 久青草视频在线观看免费| 久久久精品免费国产四虎| 免费观看激色视频网站bd| 羞羞视频在线观看免费| 亚洲综合久久久久久中文字幕| 亚洲综合色婷婷七月丁香| 亚洲色欲久久久综合网| 波多野结衣免费在线观看| 国内自产少妇自拍区免费| 曰批视频免费40分钟试看天天| 久久免费线看线看| 日韩免费a级毛片无码a∨| 午夜免费1000部| 国产一区视频在线免费观看 |