2007年9月11日 #
2007年4月25日 #
現在在干啥啊!
沒有方向,沒有動力。
十年之后會是什么樣子呢?
nnd
郁悶!
極其郁悶!!!
改變,
要改變啊!!
2006年11月27日 #
??????直接用URLEncoder.encode(fileName,"UTF-8"),得到的文件名長度會被截斷。
解決方法是:
??????文件名先用“GB2312”編碼,然后用“ISO8859_1”解碼。當然也可以在將文件名保存到數據庫之前用“GB2312”編碼。
代碼如下:

?2

?3

?4

?5

?6



?7

?8

?9

10

11

12

13

14

15

16

17

18

19

20

21

22

2006年7月26日 #
先看一下Proxy的兩種用法:






































































































看一下java api doc
static?InvocationHandler | getInvocationHandler(Object?proxy) ??????????返回指定代理實例的調用處理程序。 |
static?Class<?> | getProxyClass(ClassLoader?loader, Class<?>...?interfaces) ??????????返回代理類的 java.lang.Class 對象,并向其提供類加載器和接口數組。 |
static?boolean | isProxyClass(Class<?>?cl) ??????????當且僅當指定的類通過 getProxyClass 方法或 newProxyInstance 方法動態生成為代理類時,返回 true。 |
static?Object | newProxyInstance(ClassLoader?loader, Class<?>[]?interfaces, InvocationHandler?h) ??????????返回一個指定接口的代理類實例,該接口可以將方法調用指派到指定的調用處理程序。 |
沒時間了,先這樣吧。
?
2006年7月18日 #
2006年7月14日 #
1 .多線程中有主內存和工作內存之分, 在JVM中,有一個主內存,專門負責所有線程共享數據;而每個線程都有他自己私有的工作內存, 主內存和工作內存分貝在JVM的stack區和heap區。
2.
線程的狀態有'Ready', 'Running', 'Sleeping', 'Blocked', 和 'Waiting'幾個狀態,
'Ready' 表示線程正在等待CPU分配允許運行的時間。
3. 線程運行次序并不是按照我們創建他們時的順序來運行的,CPU處理線程的順序是不確定的,如果需要確定,那么必須手工介入,使用setPriority()方法設置優先級。
4. 我們無從知道一個線程什么時候運行,兩個或多個線程在訪問同一個資源時,需要synchronized
5. 每個線程會注冊自己,實際某處存在著對它的引用,因此,垃圾回收機制對它就“束手無策”了。
6. Daemon線程區別一般線程之處是:主程序一旦結束,Daemon線程就會結束。
7. 一個對象中的所有synchronized方法都共享一把鎖,這把鎖能夠防止多個方法對通用內存同時進行的寫操作。synchronized static方法可在一個類范圍內被相互間鎖定起來。
8. 對于訪問某個關鍵共享資源的所有方法,都必須把它們設為synchronized,否則就不能正常工作。
9. 假設已知一個方法不會造成沖突,最明智的方法是不要使用synchronized,能提高些性能。
10 . 如果一個"同步"方法修改了一個變量,而我們的方法要用到這個變量(可能是只讀),最好將自己的這個方法也設為 synchronized。
11. synchronized不能繼承, 父類的方法是synchronized,那么其子類重載方法中就不會繼承“同步”。
12. 線程堵塞Blocked有幾個原因造成:
(1)線程在等候一些IO操作
(2)線程試圖調用另外一個對象的“同步”方法,但那個對象處于鎖定狀態,暫時無法使用。
13.
原子型操作(atomic), 對原始型變量(primitive)的操作是原子型的atomic. 意味著這些操作是線程安全的, 但是大部分情況下,我們并不能正確使用,來看看 i = i + 1 , i是int型,屬于原始型變量:
(1)從主內存中讀取i值到本地內存.
(2)將值從本地內存裝載到線程工作拷貝中.
(3)裝載變量1.
(4)將i 加 1.
(5)將結果給變量i.
(6)將i保存到線程本地工作拷貝中.
(7)寫回主內存.
注意原子型操作只限于第1步到第2步的讀取以及第6到第7步的寫, i的值還是可能被同時執行i=i+1的多線程中斷打擾(在第4步)。
double 和long 變量是非原子型的(non-atomic)。數組是object 非原子型。
14. 由于13條的原因,我們解決辦法是:
class xxx extends Thread{
//i會被經常修改
private int i;
public synchronized int read(){ return i;}
public synchronized void update(){ i = i + 1;}
..........
}
15.
Volatile變量, volatile變量表示保證它必須是與主內存保持一致,它實際是"變量的同步", 也就是說對于volatile變量的操作是原子型的,如用在long 或 double變量前。
16. 使用yield()會自動放棄CPU,有時比sleep更能提升性能。
17. sleep()和wait()的區別是:wait()方法被調用時會解除鎖定,但是我們能使用它的地方只是在一個同步的方法或代碼塊內。
18. 通過制造縮小同步范圍,盡可能的實現代碼塊同步,wait(毫秒數)可在指定的毫秒數可退出wait;對于wait()需要被notisfy()或notifyAll()踢醒。
19.
構造兩個線程之間實時通信的方法分幾步:
(1). 創建一個PipedWriter和一個PipedReader和它們之間的管道;
PipedReader in = new PipedReader(new PipedWriter())
(2). 在需要發送信息的線程開始之前,將外部的PipedWriter導向給其內部的Writer實例out
(3). 在需要接受信息的線程開始之前,將外部的PipedReader導向給其內部的Reader實例in
(4). 這樣放入out的所有東西度可從in中提取出來。
20. synchronized帶來的問題除性能有所下降外,最大的缺點是會帶來死鎖DeadLock,只有通過謹慎設計來防止死鎖,其他毫無辦法,這也是線程難以馴服的一個原因。不要再使用stop() suspend() resume()和destory()方法
21. 在大量線程被堵塞時,最高優先級的線程先運行。但是不表示低級別線程不會運行,運行概率小而已。
22. 線程組的主要優點是:使用單個命令可完成對整個線程組的操作。很少需要用到線程組。
23. 從以下幾個方面提升多線程的性能:
檢查所有可能Block的地方,盡可能的多的使用sleep或yield()以及wait();
盡可能延長sleep(毫秒數)的時間;
運行的線程不用超過100個,不能太多;
不同平臺linux或windows以及不同JVM運行性能差別很大。
24. 推薦幾篇相關英文文章:
Use Threading Tricks to Improve Programs
原文:多線程設計要點? 板橋里人 http://www.jdon.com/concurrent/thread.htm
2006年7月11日 #
???
??????X/Open組織(即現在的Open Group)定義了分布式事務處理模型。X/Open DTP模型(1994)包括應用程序(AP)、事務管理器(TM)、資源管理器(RM)、通信資源管理器(CRM)四部分。一般,常見的事務管理器(TM)是交易中間件,常見的資源管理器(RM)是數據庫,常見的通信資源管理器(CRM)是消息中間件。為表述方便起見,在本文中直接以其常見表現形式進行描述。
??????一般情況下,某一數據庫無法知道其它數據庫在做什么,因此,在一個DTP環境中,交易中間件是必需的,由它通知和協調相關數據庫的提交或回滾。而一個數據庫只將其自己所做的操作(可恢復)影射到全局事務中。?
??????
??????XA就是X/Open DTP定義的交易中間件與數據庫之間的接口規范(即接口函數),交易中間件用它來通知數據庫事務的開始、結束以及提交、回滾等。XA接口函數由數據庫廠商提供。
??????通常情況下,交易中間件與數據庫通過XA 接口規范,使用兩階段提交來完成一個全局事務,XA規范的基礎是兩階段提交協議。?
??????在第一階段,交易中間件請求所有相關數據庫準備提交(預提交)各自的事務分支,以確認是否所有相關數據庫都可以提交各自的事務分支。當某一數據庫收到預提交后,如果可以提交屬于自己的事務分支,則將自己在該事務分支中所做的操作固定記錄下來,并給交易中間件一個同意提交的應答,此時數據庫將不能再在該事務分支中加入任何操作,但此時數據庫并沒有真正提交該事務,數據庫對共享資源的操作還未釋放(處于上鎖狀態)。如果由于某種原因數據庫無法提交屬于自己的事務分支,它將回滾自己的所有操作,釋放對共享資源上的鎖,并返回給交易中間件失敗應答。
在第二階段,交易中間件審查所有數據庫返回的預提交結果,如所有數據庫都可以提交,交易中間件將要求所有數據庫做正式提交,這樣該全局事務被提交。而如果有任一數據庫預提交返回失敗,交易中間件將要求所有其它數據庫回滾其操作,這樣該全局事務被回滾。
?
??????摘自http://www.huihoo.com/middleware/trade_middleware.html??? 交易中間件與XA規范
?

?2



?3

?4

?5

?6

?7



?8

?9

10

11

12



13

14

15

16

17

18

19

20



21

22

23

24

25

26

27

28

29

30

31

32



33

34

35

36

37



38

39

40

41

42

43

44

45

46

47

算是比較準的了,但還是有錯誤,而且性能比較差。
算法最初是誰寫的也忘了。呵呵,拿來用一下.