2014年6月30日
#
因为在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;
1、解压apr包到bin目录
2、在standalone.conf.bat配置目录
set "JAVA_OPTS=-Xms256M -Xmx512M -XX:MaxPermSize=128M -Djava.library.path=E:/jboss-eap-6.2/bin/native"
3、standalone.xml设置APR协议，并启用native
<subsystem xmlns="urn:jboss:domain:web:1.5" default-virtual-server="default-host" native="true">
<connector name="http" protocol="org.apache.coyote.http11.Http11AprProtocol" scheme="http" socket-binding="http"/>
<virtual-server name="default-host" enable-welcome-root="true">
<alias name="localhost"/>
<alias name="example.com"/>
</virtual-server>
</subsystem>