2014年7月17日
#
因為在jsp中對中文進行了編碼的時候用的是UTF-8的編碼方式，而在servlet中調用request.getParameter();方法的時候使用服務器指定的編碼格式自動解碼一次，所以前臺編碼一次后臺解碼一次而解碼和編碼的方式不用所以造成了亂碼的出現。
所以需要先編碼再解碼，代碼如下：
fileName=java.net.URLDecoder.decode(java.net.URLEncoder.encode(fileName,"iso8859-1"),"utf-8");
set JAVA_OPTS=-server -Xmn4096m -Xms8192m -Xmx8192m -Xss256k -XX:PermSize=128m -XX:MaxPermSize=256m -XX:SurvivorRatio=8 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=30 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 -XX:+DisableExplicitGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=2 -XX:GCTimeRatio=20 -XX:SoftRefLRUPolicyMSPerMB=0 -Xnoclassgc -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods
–XX:ParallelGCThreads=20：設置 20 個線程進行垃圾回收；
–XX:+UseParNewGC：年輕代使用并行回收器；
–XX:+UseConcMarkSweepGC：年老代使用 CMS 收集器降低停頓；
–XX:+SurvivorRatio：設置 Eden 區和 Survivor 區的比例為 8:1。稍大的 Survivor 空間可以提高在年輕代回收生命周期較短的對象的可能性，如果 Survivor 不夠大，一些短命的對象可能直接進入年老代，這對系統來說是不利的。
–XX:TargetSurvivorRatio=90：設置 Survivor 區的可使用率。這里設置為 90%，則允許 90%的 Survivor 空間被使用。默認值是 50%。故該設置提高了 Survivor 區的使用率。當存放的對象超過這個百分比，則對象會向年老代壓縮。因此，這個選項更有助于將對象留在年輕代。
–XX:MaxTenuringThreshold：設置年輕對象晉升到年老代的年齡。默認值是 15 次，即對象經過 15 次 Minor GC 依然存活，則進入年老代。這里設置為 31，目的是讓對象盡可能地保存在年輕代區域。
-XX:GCTimeRatio
通過-XX:GCTimeRatio=<value>我們告訴JVM吞吐量要達到的目標值。 更準確地說，-XX:GCTimeRatio=N指定目標應用程序線程的執行時間(與總的程序執行時間)達到N/(N+1)的目標比值。 例如，通過-XX:GCTimeRatio=9我們要求應用程序線程在整個執行時間中至少9/10是活動的(因此，GC線程占用其余1/10)。 基于運行時的測量，JVM將會嘗試修改堆和GC設置以期達到目標吞吐量。 -XX:GCTimeRatio的默認值是99，也就是說，應用程序線程應該運行至少99%的總執行時間
JDK7可以用使用G1垃圾回收器，最好堆棧大于4G情況下使用。
-Xmx24g -Xms24g -XX:PermSize=96m -XX:MaxPermSize=96m -XX:+UseG1GC -XX:SurvivorRatio=6 -XX:MaxGCPauseMillis=400 -XX:G1ReservePercent=15 -XX:InitiatingHeapOccupancyPercent=40 -XX:ConcGCThreads=8
使用G1時的最佳實踐
1、不要設置年輕代的大小（-Xmn），否則會擾亂G1的缺省行為，JVM也不會滿足用戶指定的暫停時間。而且設置了固定值的話，G1將無法隨需擴展年輕代的大小
2、GC暫停時間不是100%能保證的
3、如果GC的晉升過程中遇到堆區域溢出（使用-XX:+PrintGCDetails看到to-space overflow），可以通過下面幾種方式避免：
增加-XX:G1ReservePercent=n，缺省值是10。這可以增加可用的to-space內存
使用-XX:ConcGCThreads=n增加標記線程數目
G1常用參數
| 參數 |
描述 |
| -XX:+UseG1GC |
開啟G1 |
| -XX:MaxGCPauseMillis=n |
設置GC暫停的最大時間,這只是目標,盡量達到,默認值是 200 毫秒,過小影響吞吐量 |
| -XX:InitiatingHeapOccupancyPercent=n |
整個堆(而不是某個年代)使用量達到此值,便會觸發并發GC周期.值為0則是連續觸發,默認值為45 |
| -XX:NewRatio=n |
老年代與新生代的比值,默認值為2 |
| -XX:SurvivorRatio=n |
伊甸園代與生存代的比率,默認值為8 |
| -XX:MaxTenuringThreshold=n |
生存代存活的最大門限,默認值為15 |
| -XX:ParallelGCThreads=n |
設置垃圾回收器并行階段的線程數,默認值與JVM運行的平臺有關,將 n 的值設置為邏輯處理器的數量 |
| -XX:ConcGCThreads=n |
設置并發垃圾回收器使用的線程數,默認值與JVM運行的平臺有關 |
| -XX:G1ReservePercent=n |
設置剩余的內存量,減少躍遷失敗的可能,默認值為10 |
| -XX:G1HeapRegionSize=n |
設置G1平分java堆而產生區域的大小,默認值可以提供最大的工效性.最小值為1M,最大為32M,最多劃分1024個,建議使用默認值 |
alignTo( String/HTMLElement/Ext.Element element, [String position], [Number[] offsets], [Boolean/Object animate] ) : Ext.Element
通過指定的錨點將此元素與另一個元素對齊. 如果另一個元素時文檔document本身,則對齊到 viewport. 參數 position 是可選的, 并可以指定為以下的格式:
空白: 默認將此元素的左上角(top-left)對齊到目標元素的左下角(bottom-left),即("tl-bl").
一個錨點anchor (此設置已被廢棄,deprecated): 傳遞的錨點位置被用做目標元素的 錨點位置. 此元素將其左上角定位到另一個元素的指定的錨點. 此方法已被廢棄,最好使用下面的兩個錨點的格式.
兩個錨點anchor: 如下面的表格所示,如果參數是用破折號(-)分隔的兩個值, 那么第一個值用作此元素的錨點, 而第二個值用作目標元素的錨點(anchor point)
除了錨點, 參數 position 也支持 "?" 字符. 如果問號字符 "?" 出現在position 字符串的末尾, 則元素將試圖對齊指定的位置, 如果必要,則會被適當調整以限制在viewport中. 注意: 為了執行 viewport 的限制,被對齊的元素將可能被對齊到其他的位置. 下表是所有支持的錨點位置(anchor positions):
值 說明
----- -----------------------------
tl 左上角(top left corner) (默認值)
t 上邊界(top edge)的中心
tr 右上角(top right)
l 左邊界(left edge)的中心
c 元素的中心(center)
r 右邊界(right edge)的中心
bl 左下角(bottom left)
b 下邊界(bottom edge)的中心
br 左下角(bottom right)
用法示例:
// 使用默認的對齊位置("tl-bl", 不受限制) 將 el 對齊到 other-el
el.alignTo("other-el");
// 對齊el元素的左上角到other-el元素的右上角 (受viewport限制)
el.alignTo("other-el", "tr?");
// 對齊el元素的右下角到other-el元素的左邊界中心
el.alignTo("other-el", "br-l?");
// 對齊el元素的中心點center到other-el元素的左下角,
// 并調整 x 的位置偏移為 -6 pixels (y 位置偏移為 0)
el.alignTo("other-el", "c-bl", [-6, 0]);
import static com.sun.btrace.BTraceUtils.println;
import static com.sun.btrace.BTraceUtils.str;
import static com.sun.btrace.BTraceUtils.strcat;
import static com.sun.btrace.BTraceUtils.timeMillis;
import java.sql.Connection;
import java.util.HashMap;
import java.util.Map;
import com.sun.btrace.BTraceUtils;
import com.sun.btrace.annotations.BTrace;
import com.sun.btrace.annotations.Kind;
import com.sun.btrace.annotations.Location;
import com.sun.btrace.annotations.OnMethod;
import com.sun.btrace.annotations.ProbeClassName;
import com.sun.btrace.annotations.ProbeMethodName;
import com.sun.btrace.annotations.Return;
import com.sun.btrace.annotations.OnEvent;
import com.sun.btrace.annotations.Self;
import com.sun.btrace.annotations.TLS;
import java.lang.Appendable;
@BTrace public class DataSourceTrace {
private static Map map = BTraceUtils.newHashMap();
@OnMethod(clazz = "org.apache.commons.dbcp.BasicDataSource", method = "getConnection", location = @Location(Kind.RETURN))
public static void traceExecute(@ProbeClassName String name,@ProbeMethodName String method, @Return Connection conn) {
//BTraceUtils.println(strcat("獲取連接:",BTraceUtils.str(conn)));
Appendable buffer=BTraceUtils.Strings.newStringBuilder();
BTraceUtils.Strings.append(buffer,BTraceUtils.timestamp("yyyy-MM-dd HH:mm:ss"));
BTraceUtils.Strings.append(buffer," - ");
BTraceUtils.Strings.append(buffer,BTraceUtils.jstackStr());
BTraceUtils.put(map, conn,str(buffer));
}
@OnMethod(clazz = "org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper", method = "close")
public static void traceExecute2(@ProbeClassName String name,@ProbeMethodName String method, @Self Connection conn) {
//BTraceUtils.println(strcat("釋放連接:",BTraceUtils.str(conn)));
BTraceUtils.remove(map, conn);
}
@OnEvent
public static void exit(){
//這里打印泄漏連接的方法堆棧，運行一段時間后通過Ctrl+C,選擇2，發送事件打印
BTraceUtils.printMap(map);
}
}
為了更好的測試我們的系統在一定數據量下的運行情況，時常需要準備大量的測試數據。如果有靈活的方法可以使用，那就可以事半功倍了。
以下介紹如何在ORACLE數據庫中進行大數據量的構造方法，數據量大小均為500萬。
'''基本主鍵列'''
SELECT LEVEL AS ID
FROM DUAL
CONNECT BY LEVEL <= 5000000
'''基本的單據列'''
SELECT 'SO20121123' || LPAD(LEVEL, 5, 0) AS ORDER_NO
FROM DUAL
CONNECT BY LEVEL <= 5000000;
'''基本的日期列'''
SELECT TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE, 'J')),
TO_NUMBER(TO_CHAR(SYSDATE, 'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 AS ENTRYDATE
FROM DUAL
CONNECT BY LEVEL < 5000000;
'''特定時間范圍內'''
SELECT TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE - 10, 'J')),
TO_NUMBER(TO_CHAR(SYSDATE, 'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 / 24 AS ENTRYDATE
FROM DUAL
CONNECT BY LEVEL < 5000000;
'''隨機數據'''
SELECT DBMS_RANDOM.VALUE FROM DUAL CONNECT BY LEVEL < 5000000;
'''隨機數據范圍'''
SELECT TRUNC(DBMS_RANDOM.VALUE(0, 100))
FROM DUAL
CONNECT BY LEVEL < 5000000;
'''隨機字符串'''
SELECT DBMS_RANDOM.STRING('A', 8) FROM DUAL CONNECT BY LEVEL < 5000000;
'''復雜組合（訂單）'''
SELECT 'P-' ||
TO_CHAR((TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE - 30,
'J')),
TO_NUMBER(TO_CHAR(SYSDATE,
'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 / 24),
'YYMMDD') || '-' ||
LPAD(TRUNC(DBMS_RANDOM.VALUE(1, 100)), 5, '0') AS 訂單號,
'一般采購' AS 訂單類型,
'SO20121123' || LPAD(LEVEL, 4, 0) AS 外部訂單號,
'admin' AS 變更人,
TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE, 'J')),
TO_NUMBER(TO_CHAR(SYSDATE, 'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 AS 更新時間
FROM DUAL
CONNECT BY LEVEL < 5000000;
'''加入隨機用戶或者字符'''
SELECT 'P-' ||
TO_CHAR((TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE - 30,
'J')),
TO_NUMBER(TO_CHAR(SYSDATE,
'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 / 24),
'YYMMDD') || '-' ||
LPAD(TRUNC(DBMS_RANDOM.VALUE(1, 100)), 5, '0') AS 訂單號,
'一般采購' AS 訂單類型,
CASE TRUNC(DBMS_RANDOM.VALUE(0, 2))
WHEN 0 THEN
('SO20121123' || LPAD(LEVEL, 4, 0))
ELSE
('')
END AS 外部訂單號,
CASE TRUNC(DBMS_RANDOM.VALUE(0, 3))
WHEN 0 THEN
'admin'
WHEN 1 THEN
'steven'
ELSE
'joseph'
END AS 變更人,
TO_DATE(TRUNC(DBMS_RANDOM.VALUE(TO_NUMBER(TO_CHAR(SYSDATE, 'J')),
TO_NUMBER(TO_CHAR(SYSDATE, 'J')))),
'J') + DBMS_RANDOM.VALUE(1, 360000) / 3600 AS 更新時間
FROM DUAL
CONNECT BY LEVEL < 5000000;
Hibernate的臟檢查（dirty checking）。每次裝載一個對象到內存時，session始終跟蹤它的修改。于是每次對數據的查詢，session都將跌代所有的session中的對象并檢查臟數據，將臟數據flush到數據庫。方法1：將事務設置為只讀，然后手工flush。@Transactional(rollbackFor = RuntimeException.class,readOnly=true)public void save(TestEmployee entity) {entitymanager.persist(entity);entitymanager.flush();}方法2：在一個session中讀取、查詢大量數據對象情況下的制勝武器- FlushMode.NEVER。當然要記住，在此過程中你不可以修改這些數據，不然就真的把數據“搞臟”了。使用武器秘訣如下：FlushMode previous = session.getFlushMode();session.flush(); // who know's what been done till nowsession.setFlushMode(FlushMode.NEVER);// Do some querying// Do some more querying// Really load up that session// Execute a few more queries// Write back to some tablessession.flush();session.setFlushMode(previous);
--釋放空間
alter table tpl_order shrink space;
--重建索引
Alter index IDX_TPL_ORDER_1 rebuild;
--重新分析表
analyze table tpl_order compute statistics;
實現目標：查詢子表TEST_B的STATUS為1的記錄所關聯的父表的CODE
1、現在子表建立聚合物化視圖
CREATE MATERIALIZED VIEW LOG on test_b WITH rowid ,SEQUENCE (status,p_id) INCLUDING NEW VALUES;
create materialized view mv_test_b
BUILD immediate
refresh fast on demand
start with sysdate next sysdate+1/1440 with rowid
as
select a.p_id,COUNT(*) from test_b a where a.status=1 group by a.p_id;
2、在子表聚合物化視圖上建立日志
CREATE MATERIALIZED VIEW LOG on mv_test_b WITH rowid ,SEQUENCE (p_id) INCLUDING NEW VALUES;
3、在主表建立關聯物化視圖和日志
CREATE MATERIALIZED VIEW LOG on test_a WITH rowid ,SEQUENCE (code) INCLUDING NEW VALUES;
create materialized view mv_test_code
BUILD immediate
refresh fast on demand
start with sysdate next sysdate+1/1440 with rowid
as
select b.code,a.rowid aid,b.rowid bid from mv_test_b a, test_a b where a.p_id=b.id;