小菜毛毛技術分享

一,抽象類:abstract

    1,只要有一個或一個以上抽象方法的類,必須用abstract聲明為抽象類;

    2,抽象類中可以有具體的實現方法;

    3,抽象類中可以沒有抽象方法;

    4,抽象類中的抽象方法必須被它的子類實現,如果子類沒有實現,則該子類繼續為抽象類

    5,抽象類不能被實例化,但可以由抽象父類指向的子類實例來調用抽象父類中的具體實現方法;通常作為一種默認行為;

    6,要使用抽象類中的方法,必須有一個子類繼承于這個抽象類,并實現抽象類中的抽象方法,通過子類的實例去調用;

 

二,接口:interface

    1,接口中可以有成員變量,且接口中的成員變量必須定義初始化;

    2,接口中的成員方法只能是方法原型,不能有方法主體;

    3,接口的成員變量和成員方法只能public(或缺省不寫),效果一樣,都是public

    4,實現接口的類必須全部實現接口中的方法(父類的實現也算,一般有通過基類實現接口中個異性不大的方法來做為適配器的做法)

 

三,關鍵字:final

   1,可用于修飾:成員變量,非抽象類(不能與abstract同時出現),非抽象的成員方法,以及方法參數

   2,final方法:不能被子類的方法重寫,但可以被繼承;

   3,final類:表示該類不能被繼承,沒有子類;final類中的方法也無法被繼承.

   4,final變量:表示常量,只能賦值一次,賦值后不能被修改.final變量必須定義初始化;

   5,final不能用于修飾構造方法;

   6,final參數:只能使用該參數,不能修改該參數的值;

 

四,關鍵字:static

   1,可以修飾成員變量和成員方法,但不能修飾類以及構造方法;

   2,被static修飾的成員變量和成員方法獨立于該類的任何對象。也就是說，它不依賴類特定的實例，被類的所有實例共享

   3,static變量和static方法一般是通過類名直接訪問,但也可以通過類的實例來訪問(不推薦這種訪問方式)

   4,static變量和static方法同樣適應java訪問修飾符.用public修飾的static變量和static方法,在任何地方都可以通過類名直接來訪問,但用private修飾的static變量和static方法,只能在聲明的本類方法及靜態塊中訪問,但不能用this訪問,因為this屬于非靜態變量.

 

 

五,static和final同時使用 

   1,static final用來修飾成員變量和成員方法，可簡單理解為“全局常量”！ 

   2,對于變量，表示一旦給值就不可修改，并且通過類名可以訪問。 

   3,對于方法，表示不可覆蓋，并且可以通過類名直接訪問。

 

HTTP 狀態代碼

java工廠模式 [ 2009-2-6 16:15:00 | By: 孫大峰 ] 6 推薦 一、引子 話說十年前，有一個爆發戶，他家有三輛汽車（Benz（奔馳）、Bmw（寶馬）、Audi（奧迪）看來這人比較愛國，沒有日本車），還雇了司機為他開車。不過，爆發戶坐車時總是這樣：上Benz車后跟司機說"開奔馳車！"，坐上Bmw后他說"開寶馬車！"，坐上Audi后他說"開奧迪車！"。你一定說：這人有病！直接說開車不就行了？！ 而當把這個爆發戶的行為放到我們程序語言中來，我們發現C語言一直是通過這種方式來坐車的！幸運的是，這種有病的現象在OO語言中可以避免了。下面以Java語言為基礎來引入我們本文的主題：工廠模式！！ 二、簡介 工廠模式主要是為創建對象提供了接口。工廠模式按照《Java與模式》中的提法分為三類： 1. 簡單工廠模式(Simple Factory) 2. 工廠方法模式(Factory Method) 3. 抽象工廠模式(Abstract Factory) 這三種模式從上到下逐步抽象，并且更具一般性。還有一種分類法，就是將簡單工廠模式看為工廠方法模式的一種特例，兩個歸為一類。下面是使用工廠模式的兩種情況： 1.在編碼時不能預見需要創建哪種類的實例。 2.系統不應依賴于產品類實例如何被創建、組合和表達的細節   三、簡單工廠模式 顧名思義，這個模式本身很簡單，而且使用在業務較簡單的情況下。 它由三種角色組成（關系見下面的類圖）： 1、工廠類角色：這是本模式的核心，含有一定的商業邏輯和判斷邏輯。在java中它往往由一個具體類實現。 2、抽象產品角色：它一般是具體產品繼承的父類或者實現的接口。在java中由接口或者抽象類來實現。 3、具體產品角色：工廠類所創建的對象就是此角色的實例。在java中由一個具體類實現。 那么簡單工廠模式怎么用呢？我來舉個例子吧，我想這個比講一大段理論上的文字描述要容易理解的多！下面就來給那個暴發戶治病: P 在使用了簡單工廠模式后，現在暴發戶只需要坐在車里對司機說句："開車"就可以了。來看看怎么實現的： //抽象產品角色 public interface Car{ public void drive(); } //具體產品角色 public class Benz implements Car{ public void drive() { System.out.println("Driving Benz "); } } public class Bmw implements Car{ public void drive() { System.out.println("Driving Bmw "); } } 。。。（奧迪我就不寫了:P） //工廠類角色 public class Driver{ //工廠方法 //注意 返回類型為抽象產品角色 public static Car driverCar(String s)throws Exception { //判斷邏輯，返回具體的產品角色給Client if(s.equalsIgnoreCase("Benz")) return new Benz(); else if(s.equalsIgnoreCase("Bmw")) return new Bmw(); ...... else throw new Exception(); 。。。 //歡迎暴發戶出場...... public class Magnate{ public static void main(String[] args){ try{ //告訴司機我今天坐奔馳 Car car = Driver.driverCar("benz"); //下命令：開車 car.drive(); 。。。 如果將所有的類放在一個文件中，請不要忘記只能有一個類被聲明為public。 程序中類之間的關系如下： 這便是簡單工廠模式了。下面是其好處： 首先，使用了簡單工廠模式后，我們的程序不在"有病"，更加符合現實中的情況；而且客戶端免除了直接創建產品對象的責任，而僅僅負責"消費"產品（正如暴發戶所為）。 下面我們從開閉原則上來分析下簡單工廠模式。當暴發戶增加了一輛車的時候，只要符合抽象產品制定的合同，那么只要通知工廠類知道就可以被客戶使用了。那么對于產品部分來說，它是符合開閉原則的--對擴展開放、對修改關閉；但是工廠部分好像不太理想，因為每增加一輛車，都要在工廠類中增加相應的商業邏輯和判斷邏輯，這顯自然是違背開閉原則的。 對于這樣的工廠類（在我們的例子中是為司機師傅），我們稱它為全能類或者上帝類。 我們舉的例子是最簡單的情況，而在實際應用中，很可能產品是一個多層次的樹狀結構。由于簡單工廠模式中只有一個工廠類來對應這些產品，所以這可能會把我們的上帝類壞了，進而累壞了我們可愛的程序員:( 正如我前面提到的簡單工廠模式適用于業務將簡單的情況下。而對于復雜的業務環境可能不太適應阿。這就應該由工廠方法模式來出場了??！ 四、工廠方法模式 先來看下它的組成吧： 1、抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 2、具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。在java中它由具體的類來實現。 3、抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。 4、具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。 來用類圖來清晰的表示下的它們之間的關系： 我們還是老規矩使用一個完整的例子來看看工廠模式各個角色之間是如何來協調的。話說暴發戶生意越做越大，自己的愛車也越來越多。這可苦了那位司機師傅了，什么車它都要記得，維護，都要經過他來使用！于是暴發戶同情他說：看你跟我這么多年的份上，以后你不用這么辛苦了，我給你分配幾個人手，你只管管好他們就行了！于是，工廠方法模式的管理出現了。代碼如下： //抽象產品角色，具體產品角色與簡單工廠模式類似，只是變得復雜了些，這里略。 //抽象工廠角色 public interface Driver{ public Car driverCar(); } public class BenzDriver implements Driver{ public Car driverCar(){ return new Benz(); } } public class BmwDriver implements Driver{ public Car driverCar() { return new Bmw(); } } ......//應該和具體產品形成對應關系，這里略... //有請暴發戶先生 public class Magnate { public static void main(String[] args) { try{ Driver driver = new BenzDriver(); Car car = driver.driverCar(); car.drive(); }catch(Exception e) { } } } 工廠方法使用一個抽象工廠角色作為核心來代替在簡單工廠模式中使用具體類作為核心。讓我們來看看工廠方法模式給我們帶來了什么？使用開閉原則來分析下工廠方法模式。當有新的產品（即暴發戶的汽車）產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那么就可以被客戶使用，而不必去修改任何已有的代碼?？磥恚S方法模式是完全符合開閉原則的！ 使用工廠方法模式足以應付我們可能遇到的大部分業務需求。但是當產品種類非常多時，就會出現大量的與之對應的工廠類，這不應該是我們所希望的。所以我建議在這種情況下使用簡單工廠模式與工廠方法模式相結合的方式來減少工廠類：即對于產品樹上類似的種類（一般是樹的葉子中互為兄弟的）使用簡單工廠模式來實現。 當然特殊的情況，就要特殊對待了：對于系統中存在不同的產品樹，而且產品樹上存在產品族，那么這種情況下就可能可以使用抽象工廠模式了。 五、小結 讓我們來看看簡單工廠模式、工廠方法模式給我們的啟迪： 如果不使用工廠模式來實現我們的例子，也許代碼會減少很多--只需要實現已有的車，不使用多態。但是在可維護性上，可擴展性上是非常差的（你可以想象一下，添加一輛車后要牽動的類）。因此為了提高擴展性和維護性，多寫些代碼是值得的。 六、抽象工廠模式 先來認識下什么是產品族：位于不同產品等級結構中，功能相關聯的產品組成的家族。如果光看這句話就能清楚的理解這個概念，我不得不佩服你啊。還是讓我們用一個例子來形象地說明一下吧。 圖中的BmwCar和BenzCar就是兩個產品樹（產品層次結構）；而如圖所示的BenzSportsCar和BmwSportsCar就是一個產品族。他們都可以放到跑車家族中，因此功能有所關聯。同理BmwBussinessCar和BenzSportsCar也是一個產品族。 回到抽象產品模式的話題上，可以這么說，它和工廠方法模式的區別就在于需要創建對象的復雜程度上。而且抽象工廠模式是三個里面最為抽象、最具一般性的。抽象工廠模式的用意為：給客戶端提供一個接口，可以創建多個產品族中的產品對象。而且使用抽象工廠模式還要滿足一下條件： 1.系統中有多個產品族，而系統一次只可能消費其中一族產品 2.同屬于同一個產品族的產品以其使用。 來看看抽象工廠模式的各個角色（和工廠方法的如出一轍）： 抽象工廠角色：這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以創建對應的具體產品的對象。在java中它由具體的類來實現。 抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中一般有抽象類或者接口來實現。 具體產品角色：具體工廠角色所創建的對象就是此角色的實例。在java中由具體的類來實現。 看過了前兩個模式，對這個模式各個角色之間的協調情況應該心里有個數了，我就不舉具體的例子了。只是一定要注意滿足使用抽象工廠模式的條件哦，不然即使存在了多個產品樹，也存在產品族，但是不能使用的。

圍剿 Flash 的不僅有 HTML 5，還有 JavaScript，著名的 JavaScript 框架 jQuery 在運動特效方面已經越來越流暢，有時候你需要點一下右鍵來確認它不是 Flash。本文介紹了10個非常出色的 jQuery 運動特效，這些效果可以更有效地展示你的內容。

1. 流感導航菜單

下面的導航菜單，當鼠標在上面移動的時候，會很流暢地垂下解釋菜單，當你將鼠標在上面快速左右移動的時候，會懷疑這是 Flash。

2. 轉花燈

Roundabout 是一個 jQuery 插件，可以將一組 HTML 對象轉換為旋轉花燈的效果。

3. 拉洋片

拉洋片也許是 jQuery 最拿手的效果了。該效果在遇到 JavaScript 被禁用的場合會自動降級使用。

4. jQuery Quicksand 插件

這個讓人贊嘆的插件，可以對一組 HTML 對象重新洗牌，效果非常出眾。

5. 導航滑塊

這種風格的導航已經見于很多站點，鼠標在導航菜單上移動的時候，一個高亮指示條隨著鼠標滑動，指示當前的導航位置。

6. 文字的移動紋理

在文字上，顯示移動的紋理，效果美輪美奐。原理是，做一個帶透明文字的 PNG 圖像放在一個容器里，容器的背景放一張圖案，用 jQuery 移動容器的背景，很簡單，不過，不支持 IE6，因為 IE6 不支持 PNG。

7. jDiv: jQuery 導航 Tab

一個可以顯示豐富內容的下拉導航菜單（演示要翻墻）。

8. 基于 CSS3 和 jQuery 的半透明導航系統

鼠標在導航菜單上移動，顯示半透明的指示圖標。CSS3 做這個實在太容易了。

9. 云臺式拉洋片

常規的拉洋片效果要么左到右，要么右到左，或者垂直上下，這個 jQuery 效果可以象云臺那樣掃鏡頭。

10. SlideDeck

SlideDeck 是一種新穎的內容展示方式，有點類似 Outlook 的手風琴菜單，但視覺效果和用戶體驗更好一些。

本文來源：http://devsnippets.com/article/10-jquery-transition-effects.html

 

FCKeditor 是個開源的HTML 文本編輯器，可以讓web 程序擁有如MS Word 這樣強大的編輯功能。等等。但是，它有一個不足之處是只有三個皮膚。而且看起來也都不怎么好看。針對此問題，我們就來探討一下FCKeditor如何更換與創建皮膚。

我們找到FCKeditor目錄里的fckconfig.js文件，用記事本打開。找到下面這一句

   1. FCKConfig.SkinPath = FCKConfig.BasePath + 'skins/default/' ;

這就是默認的皮膚文件設置?？梢詫⒑竺娴膁efault設置成其它的。自帶的三套皮膚目錄分別是：default、office2003和silver。更改完成后清空一下緩存。再次打開帶有編緝器的網頁。我們可以發現編緝器的風格已經改變了。

由于FckEditor for java 2.4相對于2.3而言做了許多改變，這些改變使得我們的Fckeditor配置起來更方便。例如：

基礎包名從：com.fredck.FCKeditor 改為 net.fckeditor.

文件上傳SimpleUploaderServle整合到了ConnectorServlet里面，WEB,XML的配置就簡單多了，下面通過一個實例說明配置詳細步驟

1、首先登陸www.fckeditor.net/download下載FCKeditor的最新版本，需要下載2個壓縮包，一個是基本應用。另一個是在為在jsp下所準備的配置。

最新版本為：FckEditor2.6.3和FckEditor for java 2.4

FCKeditor 2.6.3下載地址：sourceforge.net/project/downloading.php     
       具體下載地址：http://easynews.dl.sourceforge.net/sourceforge/fckeditor/FCKeditor_2.6.3.zip
       FCKeditor for Java 下載地址：sourceforge.net/project/downloading.php
     具體下載地址：http://switch.dl.sourceforge.net/sourceforge/fckeditor/fckeditor-java-2.4-bin.zip（發行版，如果需要源碼或者demo包請另行下載）

請下載demo包，否則會出現留言中那位朋友的錯誤！

下載之后分別為：FCKeditor_2.6.3.zip 和 fckeditor-java-2.4-bin.zip（fckeditor-java-demo-2.4.war）將它們分別解壓。

2、首先在MyEclipse(或者其他的IDE)下建立一個新項目例如：FckedtiorTest 即http://localhost:8080/FckeditorTest

現在將解壓后的FCKeditor_2.6.3.zip 里面的fckeditor文件夾拷貝到當前的項目文件夾里面。我的demo項目目錄結構如下：

         3、配置web.xml。配置文件如下，這就是全部了，其他的不需要再配置，由于SimpleUploaderServle整合到了ConnectorServlet里面，所以文件上傳等都不需要再配置。

<servlet>    <servlet-name>Connector</servlet-name>    <servlet-class>     net.fckeditor.connector.ConnectorServlet    </servlet-class>    <load-on-startup>1</load-on-startup> </servlet> <servlet-mapping>    <servlet-name>Connector</servlet-name>    <url-pattern>     /fckeditor/editor/filemanager/connectors/*    </url-pattern> </servlet-mapping>

4、在src目錄下面建立fckeditor.properties資源文件，在里面寫入這么一行“connector.userActionImpl=net.fckeditor.requestcycle.impl.UserActionImpl”

5、下面寫測試頁面：

     index.jsp

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%> <%@ taglib uri=" <html> <head>        <title>FckEditor測試</title> </head> <body style="text-align: center;"> <div style="text-align: center;width: 600pt"> <h2>FckEditor測試</h2> <hr> <form action="ShowData.jsp" method="post">      <FCK:editor instanceName="test" height="400pt">    <jsp:attribute name="value"> 這里是<a href="    </jsp:attribute> </FCK:editor>         <input type="submit" value="提交"/>    <input type="reset" value="重置"/>    </form> </div> </body> </html>

 

   顯示數據的頁面：ShowData.jsp

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <head>    <title>FCKeditor - 顯示數據</title>    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> </head> <%    request.setCharacterEncoding("UTF-8");    String data = request.getParameter("test"); %> <body>    <h1>FCKeditor - 顯示數據</h1>      <hr/><br />    <%=data%> </body> </html>

6、結果截圖

index.jsp

ShowData.jsp

7、給FckEditor瘦身

      刪除fckeditor目錄下面所有以“_”開頭的文件或者文件夾，像"_samples"、"_documentation.html“等

     刪除fckeditor目錄下面除了，fckconfig.js   fckpackage.xml fckstyles.xml   fcktemplates.xml外的所有文件，當然要保留editor文件夾

     刪除fckeditor/editor/lang目錄下面除了en.js、 zh-cn.js外的所有文件

     刪除fckeditor\editor\filemanager目錄下面的connectors文件夾

     刪除editor\skins目錄下面除了default下面的文件夾，這個里面是皮膚，共有三種，可以在fckconfig.js里面設置。

PS：demo下載：http://www.namipan.com/d/7218d2c0bf3e33e8aedf972b41d5d09f3efab0d8f53b0900

再PS:有關中文亂碼問題請參考：http://hi.baidu.com/huqiwen/blog/item/c709aa18fa187a0135fa4103.html

http://133.61.8.59:7001/index_zh_CN.jsp 相關文檔
http://localhost:7001/console WEB控制

現在要求您診斷 WebLogic J2EE 應用程序中的性能問題。因為 Java 系統是如此復雜，所以診斷 WebLogic J2EE 應用程序中的性能問題就有點像診斷疑難雜癥。
為了正確地找到問題所在，您需要對癥狀有全面了解，要做好準備進行大量研究工作，最后您需要制定正確的治療方案。本文討論了 J2EE 應用程序性能問題的一些最常見類型和它們產生的原因，以及如何正確地診斷和消除它們的推薦指導原則。


癥狀
　　WebLogic 應用程序性能問題的癥狀是什么？您看到的癥狀可以指導您在所有可能的問題中進行搜索。請準備一個筆記本并開始向人們調查。試著把對問題根本原因的推測和假設與系統行為的實際證據分離。下面是一個常見癥狀集的列表： 持續緩慢：應用程序一直特別慢。改變環境因素(負載、數據庫連接數量)對整體響應時間的改變很小。 隨著時間推進越來越慢：系統運行時間越長(負載相對均衡不變的情況下)，就變得越慢。有可能是(最后)達到了某個閾值，系統被鎖定或者由于大量錯誤而崩潰。 隨著負載增加越來越慢：每增加一個額外用戶，應用程序就變得越慢。如果用戶離開系統，系統就“冷卻下來”，恢復正常。 零星的掛起或者異常錯誤：偶爾(可能由于負載或某些其它原因)，在頁面無法完成或者出現追蹤到異常和堆棧的錯誤頁時，用戶會看到掛起的情況。掛起的數量可能不同，但總是無法完全消除，甚至在強化 (“burn in”) 期間之后也是如此。 可以預見的鎖定：首先出現一些掛起或錯誤，然后加速出現，直到系統完全被鎖定。通常這些問題可以通過“重新啟動來管理”的方式解決。 突然混亂：系統一直運行正常，相當一段時間里(可能一個小時，也可能是三天)性能都還差強人意，但是“突然某個時候，根本沒有任何原因的”，系統開始出現大量錯誤，或者被鎖定。

為什么問題診斷如此復雜？ 軟件開發網
　　對于 WebLogic 應用程序的某個具體應用模式來說，沒有既定的公式可以用來推導出它的性能(在嚴格的實時工程當中，速度單調分析這類技術確實可以做這項工作，但是在本文里還是讓我們忘記它吧)。網絡上是否存在另外一個系統正在密集使用一個共享的后端服務，對于實際產生的性能有很大影響。性能也許還取決于 JDBC 驅動程序版本和數據庫的正確匹配。也許開發人員三年前寫的一些代碼恰巧在這個時候才出現特定類型的異常，而您急切需要的解決問題回饋，卻恰恰包含在這個異常里。
　　從本質上說，典型業務系統的性能是由成千上萬交互的變量和決策共同作用的結果。就像人體一樣，有太多連鎖著的部分和過程，所以很難理解系統的整體。因此我們進行了簡化，并求助于拱形模式。

疾病
　　您看到的癥狀的根本原因是什么？它是初級流行性感冒或者是肺炎的開始嗎？是應用程序內部的底層問題還是它所在的 JVM 外部的問題？請參閱表 1 中應用程序性能低下的一些最常見原因。

 

表1

 

毛病 描述 癥狀 原因或治法 線性內存泄漏 每單位(每事務、每用戶等)泄漏造成內存隨著時間或負載線性增長。這會隨著時間或負載增長降低系統性能。只有重啟才有可能恢復。 隨著時間越來越慢
隨著負載越來越慢 雖然可能有多種外部原因，但最典型的是與資源泄漏有關(例如，每單位數據的鏈表存儲，或者沒有回收的回收/增長緩沖區)。 指數方式內存泄漏 雙倍增長策略的泄漏造成系統內存消耗表現為時間的指數曲線 隨著時間越來越慢
隨著負載越來越慢 通常是由于向集合(Vector，HashMap) 中加入永遠不刪除的元素造成的。 糟糕的編碼：無限循環 線程在 while(true) 語句以及類似的語句里阻塞。 可以預見的鎖定 您需要對循環進行大刀闊斧的刪剪。 資源泄漏 JDBC 語句，CICS 事務網關連接，以及類似的東西被泄漏了，造成對 Java 橋接層和后端系統的影響。 隨著時間越來越慢
可以預見的鎖定
突然混亂 通常情況下，這是由于遺漏了 finally 塊，或者更簡單點，就是忘記用 close() 關閉代表外部資源的對象所造成的。 外部瓶頸問題 后端或者其他外部系統（如鑒權）越來越慢，同樣減緩了 J2EE 應用服務器和應用程序 持續緩慢
隨著負載越來越慢 咨詢專家（負責的第三方或者系統管理員），獲取解決外部瓶頸問題的方法。 外部系統 J2EE 應用程序通過太大或太多的請求濫用后端系統。 持續緩慢
隨著負載越來越慢 清除冗余的工作請求 ，成批處理相似的工作請求，把大的請求分解成若干個更小的請求，調整工作請求或后端系統(例如，公共查詢關鍵字的索引)等。 糟糕的編碼：CPU密集的組件 這是 J2EE 世界中常見的感冒。一些糟糕的代碼或大量代碼之間一次糟糕的交互，就掛起了 CPU，把吞吐速度減慢到爬行的速度。 持續緩慢
隨著負載越來越慢 典型的解決方案就是數據高速緩存或者性能計數。 中間層問題 實現得很糟糕的橋接層(JDBC 驅動程序，到傳統系統的 CORBA 連接)，由于對數據和請求不斷的排列、解除排列，從而把所有通過它的流量減慢到爬行速度。這個毛病在早期階段很容易與外部瓶頸混淆。 持續緩慢

隨著負載越來越慢 檢查橋接層和外部系統的版本兼容性。如果有可能，評估不同的橋接供應商。如果重新規劃架構，有可能完全不需要橋接。 內部資源瓶頸：過度使用或分配不足 內部資源(線程、放入池的對象)變得稀缺。是在正確使用的情況下加大負載時出現過度使用還是因為泄漏？ 隨著負載越來越慢
零星的掛起或異常錯誤 分配不足：根據預期的最大負載提高池的最大尺寸。過度使用：請參閱外部系統的過度使用。 不停止的重試 這包括對失敗請求連續的(或者在極端情況下無休止的)重試。 可以預見的鎖定
突然混亂 可能就是后端系統完全宕機。在這里，可用性監控會有幫助，或者就是把嘗試與成功分開。 線程：阻塞點 線程在過于積極的同步點上備份，造成交通阻塞。 隨著負載越來越慢
零星的掛起或異常錯誤
可以預見的鎖定
突然混亂 可能同步是不必要的(只要重新設計)，或者比較外在的鎖定策略(例如，讀/寫鎖)也許會有幫助。 線程：死鎖/活動鎖 最普遍，這是您基本的“獲得順序”的問題。 突然混亂 處理選項包括：主鎖，確定的獲得順序，以及銀行家算法。

測量關鍵的統計指標

　　當您負責診斷問題的時候，您應當能夠跟蹤關于您的 WebLogic 應用程序健康情況的關鍵統計指標。您能測量什么？有什么工具可以提供幫助呢？

 

使用的全部內存：在不同級別上 (JVM 堆棧，操作系統)，Java 堆棧 profiler 對堆棧的正確使用提供了可見性；像 top ,vmstat 以及 Windows Perfmon 這樣的工具在操作系統級別上為內存使用提供可見性。察看 Java 堆棧的一個簡單的聚合視圖，請打開—verbose：gc 開關(如果在您的 JVM 上可以使用的話)。 CPU 時間：合并(可以通過使用 top 等方式得到)每個組件或每種方法。其中某些指標可以通過 WebLogic 管理控制臺得到。也可以通過 Java profile 使用它們。 計時 (a.k.a.“實” 時)：每事務，每組件，每方法；可以按統計平均值或單獨的數據點查看。Java profiler 可以產生一些這樣的數據，但是使用程序監控解決方案可能是您的最佳選擇。 內部資源：
分配的數量，使用的數量，等待的客戶數量，獲得資源的平均等待時間，使用資源平均消耗的時間，使用資源完成請求工作時使用的平均時間。應用程序服務器通常會給出這些數字的最小可視性。 外部資源：分配的數量，使用的數量，等待的客戶數量，平均等待時間，加上對這些外部系統的直接測量(例如查看它能多快完成請求的工作)。不要忘記運行應用程序服務器的操作系統和硬件也是“外部資源”-例如，是否您使用了太多的進程或端口？可以用兩種形式測試這些資源—從 JVM 內部測試提供資源的橋接層，用外部資源本身的工具測量外部資源。 網絡應用：帶寬使用，延遲。雖然操作系統自帶的工具(例如 netstat)也有助于做這些工作，但是網絡嗅探器設備可以深入了解這些信息。 系統狀態：用線程清除，日志和跟蹤文件，堆棧跟蹤等等?；蛘咴诟顚哟紊希拖裾{試器中查看的那樣使用變量的值。

實驗工作
　　有的時候，在一次標桿運行中獲得的數據，不足以揭示答案。那么找到答案的機會就在于您還有些有限的預算，可以運行試驗或者做實驗工作，來完成診斷。您可以運行什么類型的試驗呢？您可以修改、觀察什么變量呢？

http://www.mscto.com

 

嘗試觀察系統行為在一段時間上的變化。應用一個衡定的負載，并觀察您的指標隨時間發生的變化。您可能會看到某些趨勢，短則一小時就可看到，長則二三天。例如，您可以看到內存使用隨著時間而增長。隨著使用的內存數量達到上限， JVM 花在搜索垃圾上的時間和操作系統花在分配內存頁面上的時間開始減少用戶事務的整體響應時間。當拋開 GC 的時候，垃圾搜集的整個過程可能過長，從而造成執行中的事務超時和異?！，F在可以開始查找資源泄漏或內存泄漏了。 嘗試在系統上改變負載。 采用三到四種工作負載(例如，10個，50個和100個用戶)，并搜集每個負載的數據。分析一下您對這些負載的測量情況。例如，您可能發現，當您的賬戶登錄 servlet 的響應時間無論如何都會低于 50 毫秒的時候，計算銷售稅的 EJB 卻隨著用戶數據的增長，速度呈線性下降。如果這個 EJB 性能在負載下的差異能解釋整體響應時間性能在負載下的增長，那么現在就是深入分析這個組件的時候了。謹記一定還要把負載恢復原狀，并查看系統是否復原。 嘗試把系統分成小單元，針對每個單元輪流進行壓力測試。 選擇一個或多個坐標系對系統進行劃分。主要的一個是系統面上的層：負載均衡器、Web 服務器、WebLogic Server，以及后端。其它示例包括用戶賬戶，內部組件，事務類型，以及單獨的頁面。假設您選擇了用戶賬戶。在用戶 A 的賬戶下運行一些負載，然后再在用戶 B 的賬戶(應當非常不同)下運行某些負載；比較兩次運行間不同的測量結果?；蛘?，輪流選擇您使用的后端系統，分別對使用每個后端系統比較重的應用程序組件進行壓力測試。具體要選擇哪個坐標進行劃分，完全取決于您要證明或者否定哪個假設。下面是一些具體想法：
　　- 如果某個用戶的登錄看起來造成了問題，那么有可能是這個用戶賬戶檔案(例如，裝入 2,000 個訂單的完整采購歷史)，或者可能是他使用系統的方式(例如，頁面訪問的順序，或者他用來查找某個文檔的查詢字符串的正確性)。
　　- 如果您使用的是一個集群系統，請嘗試以單臺機器為單位劃分。盡管盡了最大努力，有的時候還會有一些機器沒有安裝最新的應用服務器或者操作系統補丁，這就會造成不同的性能特征。而且，還請注意負載均衡器，或者保姆進程，查看它們是否公平地分配了工作并跟蹤了進入請求。

診斷：測試您的推測
　　在這個時候，您應當已經有了足夠的信息，可以形成關于性能瓶頸原因的推測了(請參閱表 1)。為了驗證您的推測是否正確或者在多個備選的推測之間進行篩選，您需要分析更多的信息或者在系統上運行更多的標桿測試。這里是一些可以幫助您的指導意見：
區分糟糕的編碼(或者是應用程序組件或者是橋接層)和瓶頸 (內部的或外部的)，請查看整體的 CPU 使用情況。如果它在負載下沒變化，但是整體響應時間變化了，那么就是應用程序花費了它的大多數時間來等待。 僅僅是因為好像是外部資源的問題，不代表您就可以立刻把責任推到資源上。 例如，分層或聯網的問題，也能造成數據庫看起來很慢，雖然實際上它并不慢。或者，更簡單一點，您對數據庫的請求可能是不合理的(每次用戶登錄的時候，都要進行三個表之間的 200 萬行記錄合并)。應當一直把橋接層的響應時間(例如，JDBC 驅動器)和資源提供的時間或者工具提供的時間進行比較(例如，DBA Studio)。 結構化的圖表有助于您理解系統內部的整體交互，但是不要忘記地圖并不是領地。.編碼錯誤或者對架構意圖的誤解，有可能使系統的實際行為與期望的行為不同。請相信性能工作提供的實際數據，而不要相信一個聲稱“每個用戶事務將只會發布一個 SQL 語句”這樣的文檔。 使用 Occam 軍刀。 假設您有兩個備選推測，一個是：在 200 萬行代碼里，有一個編碼糟糕的組件，直到上周這個組件才集成進來；另一個是 JVM 的即時編譯器生成了糟糕的機器碼，破壞了這個變量的內存完整性。除非您有具體的數據來證實，否則(我已經看到了第二種情況發生)，請更詳細地檢查第一個假設。J2EE 系統確實容易出錯，但是不要讓這一點就妨礙您先測試一個更簡單的假設。 日志文件中沒有錯誤不代表不存在錯誤。 有許多原因可以造成不在日志里寫下異常；可能是因為程序員認為某件事“永遠不會發生”，于是就排除了這個異常；也可能是因為某些組件可以使用故障恢復機制，所以就沒有記錄第一次故障。

示例診斷
　　讓我們來實際研究一個示例。您的 WebLogic 應用程序表現出在負載下越來越慢的癥狀。您加入的用戶越多，系統越慢。一旦消除負載，系統就冷靜下來，沒有任何后遺癥。您對這一主要癥狀進行測試，發現并得到圖 2 所示的以下結果(時間測量針對的是單一典型事務的端到端完成時間)。

表2

負載(用戶數) 來回用時(毫秒) 10 300 50 471 100 892 150 1067

應用程序性能在負載下越來越慢

http://www.mscto.com

 

　　您形成了幾個假設。也許這里的毛病是一個糟糕編碼的組件，也許是后端系統的瓶頸。它可能是一個同步阻塞點。您怎樣才能分清它們的不同呢？假設您還測試了應用程序服務器在負載運行期間的CPU整體使用情況，并得到了表 3 所示的結果。

表3

 

負載(用戶數) 來回用時(毫秒) 整體 CPU 時間(%) 10 300 30 50 471 33 100 892 37 150 1067 41

問題看起來好像是“等待”瓶頸

 

　　現在看起來，系統不是 CPU 密集型的，這就是說它的多數時間都花在等待上了。那么是它的內部(例如，同步交通阻塞)或外部(緩慢的數據庫)的問題？好，讓我們假設我們還稍微多搜集了一些數據，如表 4 所示。

 

表4

負載(用戶數) 等待數據庫連接的線程數量 JDBC 查詢用時(毫秒) 10 2 58 50 3 115 100 3 489 150 4 612

問題是否出在一個緩慢的 SQL 語句上呢？

現在看起來并不是內部等待數據庫連接的瓶頸，相反，好像是 JDBC 查詢本身的問題。JDBC 查詢不僅隨整體事務時間的不同而不同，而且它糟糕的性能還解釋了整體性能糟糕的原因。但是，我們還不能完全確定。您仍然還有三個主要的假設要排序：是否數據庫本身慢？應用程序是否對數據庫進行了不合理的請求？或者問題是不是出在應用程序和數據庫之間的某個層上？您拿出數據庫供應商專用的工具，從它的角度查看響應時間。假設您看到如表 5 所示的數字。

表5

 

負載(用戶數) JDBC 查詢計時(毫秒) DB SQL 執行的時間(毫秒) 10 58 43 50 115 97 100 489 418 150 612 589
實際是數據庫中的 SQL 語句慢

　　如果您沒有看到這條信息，那么您可能要返回 JDBC 驅動程序，期待能夠發現其中的某些同步問題(請記住，CPU 沒有被抑制)。幸運的是，在這個案例里，您已經把具體問題的范圍縮小到數據庫查詢上。找出查詢請求是否足夠合理，需要一些相關領域的知識，需要熟悉系統，但是在這個案例里，它也許就是發現查詢把非索引字段和外鍵進行了比較。您和 DBA 協作，它修改索引方案，讓查詢變得更快，而您則找到了您的藥方。

結束語
　　診斷 WebLogic J2EE 應用程序的性能瓶頸是一個艱苦的旅程。請隨時保持清醒，把事實與推測分開，總是用實際的證據來確認您的推測。我希望給您帶來了思考和實踐問題的一些有用的想法的分類。就像調試，這仍然是一項不明確的藝術，但是深思熟慮會帶您走出困境。祝您好運!

 

關于作者
　　John Bley 是 Wily Technology 的軟件工程師。他有豐富的 Java 編程和架構經驗。為了撰寫本文，他總結了 Wily 的企業客戶的經驗，Wily負責管理復雜的 J2EE 環境。(更多)
原文出處 http://www.sys-con.com/story/?storyid=43024&DE=1

Google近日推出了一款網站性能優化工具：Page Speed（http://code.google.com/speed/page-speed/）。它旨在幫助站長與網站開發者分析網站中存在的性能方面的問題，并有針對性地提出改進意見。Page Speed在功能方面極其類似于Yahoo!的網站性能優化YSlow，不過YSlow要比Page Speed推出早得的多。它們都是基于Firebug的Fireffox插件，使用方法也類似。這里我主要介紹一下Google新推出的Page Speed的使用，對Yslow感興趣的朋友可以參照我以前的這篇文章《你的網站為什么會慢？——用YSlow為你的網站提速》，同時還有我翻譯的Yahoo!的文章Yahoo!網站性能最佳體驗的34條黃金守則——內容、JavaScript和CSS、服務器、圖片、Coockie與移動應用，相信一定會對你提高網站性能有幫助。

一、Page Speed的安裝及使用

Page Speed是一款Firefox插件，同時他依附于別款插件Firebug，也就是說你的Firefox瀏覽器中必須已經安裝了Firebug才能安裝Page Speed。安裝環境為Firefox 3.0.4以上，Fireug 1.3.3以上。

Page Speed的使用也很簡單，在Firefox中點擊右下角的Firebug圖標啟動后，再點擊Page Speed選項卡即可。要注意的是，你要對你網站內的某個頁面進行性能分析，你必須先把該頁面加載完成后才能使用Page Speed，也就是說只有在瀏覽器左下角出現“Done”或者"完成"之后才可以啟用Page Speed進行分析。如果頁面中流媒體，可能不會現在“完成”，這種情況要等到流媒體可以播放。

 

然后點擊“Analyze Performance”（性能分析），這時Page Speed會根據web performance best practices （網頁性能最佳實踐）進行逐項打分。然后根據重要程序和優先級對每項進行排列。

此外，你還可以點擊每條建議前面的“加號”展開查看詳細的描述，或者直接點擊每條規則相看該規則的具體內容，還可以點擊“Show Resource”（查看來源）來查看每條建議是針對頁面中哪部分內容提出的。

對于分析結果中的符號說明一下：

1. 紅色感嘆號代表高優先級提示，表示這一項嚴重影響了你的頁面性能，你需要優先對其進行性能優化；
2. 橙色三角代表此項提示需要引起你的注意，并進行適當改進；
3. 綠色的對號代表該項規則在你的網站中應用得到，你在修改了前面兩部分的提示之后，它們有可能變為綠色的對號；
4. 藍色消息符號是為你提供了額外的幫助信息，請稍加留意（需要注意的是，如果你的頁面中出現了大量的此類符號，可能是因為你在頁面加載完成之前就進行了網站性能分析）。

二、活動記錄

活動記錄是一條頁面活動的時間軸，它記錄了包括網絡事件、JavaScript運行在內的所有瀏覽器活動。你可以使用它并配合性能分析中的數據進一步對網站性能做出評估。

• 查看頁面運行過程中所耗費的時間，以毫秒計算；
• 查看瀏覽器事件，包括頁面加載完成后的事件；
• 區分造成頁面響應緩慢的原因，其中包括網絡來時、DNS查找、連接建立、JavaScript運行等；
• 獲取在特定時間或者事件下才響應的JavaScript事件列表；
• 可以對其它標簽或者窗口中打開的頁面進行分析；
• 多頁面加載時的頁面加載順序；
• 對根據Page Speed優化前后的表現進行對比。

三、理解Page Speed中的事件

頁面記錄選項卡下是通過時間線來記錄各種資源加載到頁面所有需要的時間。事件的記錄時間間隔為10毫秒，如果事件需要的時間少于10毫秒那么它將用較短的色塊來表示。時間線中沒有任何顏色的表示，在瀏覽器事件的運行依賴于其它進程，如DOM和CSS渲染、Flash ActionScript、渲染、操作系統事件等。

網絡事件		描述
	DNS	瀏覽器查找DNS所需要的時間
	t連接等待	瀏覽器與網站服務器建立連接（TCP）需要一定的時間。由于瀏覽器可以打開的連接數目是有限的，如果達到這個限制他必須等其它連接關閉之后才能再重新建立一個新的連接。（更多關于瀏覽器連接的信息可以參照Parallel downloads across hostnames）。 這個事件顯示了瀏覽器等其它連接完成的時間。
	連接	瀏覽器和web服務器建立連接。這個事件只有打開新連接時出現，已有連接重新打開使用不包含在內。
	請求發送	瀏覽器發送的HTTP請求。只顯示GET方式的請求。
	已連接	瀏覽器通過網絡等待接收數據。事件隨著瀏覽器TCP連接的結束而結束。
本地事件		描述
	緩存	瀏覽器成功將內容加入到緩存中。
	可用數據	可用于瀏覽器呈現的數據。由于web服務器發送大量的數據，如果文件很大那么有可能一個資源會出現多個該事件。
	獲取JS	瀏覽器獲取JavaScript。該事件可能會延緩其它事件，如果此種情況出現，將會在其下一行列出。
	運行JS	瀏覽器執行JavaScript。該事件可能會延緩其它事件，如果此種情況出現，將會在其下一行列出。如果獲取JS和運行JS中間有時間間隔，這說明源文件中包括有延時功能的函數。

此外，Page Speed還包括了對已完成的JavaScript函數的信息搜集功能，當頁面中的JS函數一旦運行，PageSpeed就會捕捉到相關信息。不通過對Page Speed進行設置還可以對未觸發函數、延時加載函數等進行收集。

下面的圖片顯示了7800毫秒時已經加載但還未觸發的函數列表：

而下面則顯示是已經觸發運行了的JS函數：

此外Pge Speed還有諸如JavaScript函數控制、瀏覽器User Agent設置等更高級功能。具體使用大家可以與YSlow對比一下。

相信，用好這兩款工具，對于站長和網站開發者來說會有極大的幫助。

本文網址： http://www.dudo.org/article/NewSoftware/using_google_page_speed.htm
轉載請注意出處

最近在項目中需要用到用到JavaScript開發工具的支持，于是乎找到了曾經了解過但是并沒有具體用過的aptana。

         Aptana是一個開發Ajax的很好的ide，甚至該公司已經有自己的單獨的Ajax Server和框架的支持。而且，至少到目前為止筆者所用過的支持JavaScript的ide中，aptana是最好的一個。且aptana提供了eclpse的插件，用起來幾乎很上手而且很簡單、方便，沒有理由不去愛它。

         但是在MyEclipse下安裝aptana總會遇到一些問題，筆者 也一樣遇到了許多問題?，F在這里就做一個總結，安裝aptana遇到的問題：

1、安裝以后必須有Firefox支持。

          因為aptana需要firefox 的JavaScript調試工具做調試，因此如果你安裝過了aptana之后系統沒有安裝firefox，那么，還是推薦你安裝一個firefox吧。即使不用這個瀏覽器也可以安裝上，省的出現一些其他的不可預料的問題。

         2、安裝過程中出現無法下載或者不兼容的問題。

         這個問題正式困擾我好幾天的問題。如果aptana安裝不上或者安裝之后出現錯誤，一般都是aptana和myeclipse或者eclipse的版本問題，因此請下載之前認真閱讀官方網站的資料以及版本的限制。一般說來，你使用的myeclipse版本越高，那么對應的aptana的版本就需要越高。筆者使用的MyEclipse完整版6.0，配上最新的aptana的eclipse插件。

         3、是自動在線下載安裝？還是link方式安裝？

         筆者推薦使用后者，也就是手動配置link的方式安裝aptana插件。這樣可以避免許多問題。筆者前幾次安裝aptana插件都失敗，原因就在于是自動下載安裝的，可每次都會出現錯誤，而改用手動配置link的方式安裝后，一切問題迎刃而解了。

         那么，跟著我一起來試試吧。

         1、先去aptana的官方網站下載eclipse的插件

         地址：http://update.aptana.com/update/studio/3.2/ 

         強烈推薦手動下載插件的方式而不是在線升級的方式，尤其你用的不是eclipse而是完整安裝版的myeclipse。

          2、手動以link方式安裝aptana插件

          首先在你的myeclipse目錄下打開eclipse文件夾：

 然后將下載后的aptana插件文件解壓縮到任何目錄（筆者解壓縮到了eclipse所在的目錄）。再在links文件夾中新建一個文本文件aptana.link，其內容形式為：

         path={aptana插件存放的位置} 

例如筆者的link文件內容為：

path=C:\\Program Files\\Eclipse-6.0M1\\eclipse\\Aptana

然后，重啟myeclipse就可以發現可愛的aptana的界面菜單了

 

    （如果安裝過程中出現問題，請留言。）

接下來就可以發現其偉大的特點了。

       將Aptana編輯器設置成myeclipse默認的編輯器

如果我們想把aptana的編輯器設置成myeclipse默認的編輯器的話，那么可以在多做一點事情，這樣方便我們今后的開發了。筆者也正式如此。 

 

在Window菜單中找到Preferences，打開的菜單中左邊的樹中展開General，找到editor

點擊File Associations，然后在上邊選擇要設置的文件后綴名，在下邊找到aptana相應的編輯器，然后點“default”即可完成默認的設置了。很簡單的，試試吧。

 

 

 相關鏈接：eclipse在線更新地址http://update.aptana.com/update/studio/3.2/ 

官方相關介紹:http://www.aptana.com/docs/index.php/Plugging_Aptana_into_an_existing_Eclipse_configuration

 

 原文地址：http://werr1985.javaeye.com/blog/288777

如果上述操作還不能安裝的話：
請將aptana插件中的features,plugins的文件復制或者剪切到E:\MyEclipse 6.0\eclipse下面的相應文件夾里面，以后保準能運行
而且需要再windows-屬性-aptana-my aptana/message center
把use firefox...前面的復選框的狗狗去掉
即可正常使用啦