1.文件上傳，ajax引入common，在jsp中進行上傳
2.webservice 客戶端連接用axis2.jar連接，用axis2的包進行創建
或者用xfx配置發布
3.文件解析，將文件轉換成i
4.ftp文件上傳下載
5.網上銀行農行校驗
6.聯動用ajax
7.dwrajax
8.郵件發送功能
9.短信發送功能
10.任務定時功能
http://blog.sina.com.cn/s/blog_6aefe42501018wnn.html
1緩存為什么要存在?
2緩存可以存在于什么地方?
3緩存有哪些屬性?
4緩存介質?
搞清楚這4個問題,那么我們就可以隨意的通過應用的場景來判斷使用何種緩存了.
1. 緩存為什么要存在?
一般情況下,一個網站,或者一個應用,它的一般形式是,瀏覽器請求應用服務器,應用服務器做一堆計算后再請求數據庫,數據庫收到請求后再作一堆計算后把數據返回給應用服務器,應用服務器再作一堆計算后把數據返回給瀏覽器.這個是一個標準流程.但是隨著互連網的普及,上網的人越來越多,網上的信息量也越來越多,在這兩個越來越多的情況下,我們的應用需要支撐的并發量就越來越多.然后我們的應用服務器和數據庫服務器所做的計算也越來越多,但是往往我們的應用服務器資源是有限的,數據庫每秒中接受請求的次數也是有限的(誰叫俺們的硬盤轉速有限呢).如果利用有限的資源來提供盡可能大的吞吐量呢,一個辦法:減少計算量,縮短請求流程(減少網絡io或者硬盤io),這時候緩存就可以大展手腳了.緩存的基本原理就是打破上圖中所描繪的標準流程,在這個標準流程中,任何一個環節都可以被切斷.請求可以從緩存里取到數據直接返回.這樣不但節省了時間,提高了響應速度,而且也節省了硬件資源.可以讓我們有限的硬件資源來服務更多的用戶.
2 緩存可以存在于什么地方?
Java代碼
瀏覽器---?瀏覽器和app之間---?分過層的app-?數據庫
瀏覽器---?瀏覽器和app之間---?分過層的app-?數據庫
在上圖中,我們可以看到一次請求的一般流程,下面我們重新繪制這張圖,讓我們的結構稍微復雜一點點.
(將app分層)
瀏覽器---?瀏覽器和app之間---?分過層的app-?數據庫
理論上來將,請求的任何一個環節都是緩存可以作用的地方.第一個環節,瀏覽器,如果數據存在瀏覽器上,那么對用戶來說速度是最快的,因為這個時候根本無需網絡請求.第二個環節,瀏覽器和app之間,如果緩存加在這個地方,那么緩存對app來說是透明的.而且這個緩存中存放的是完整的頁面.第三個節點,app 中本身就有幾個層次,那么緩存也可以放在不同的層次上,這一部分是情況或者場景比較復雜的部分.選擇緩存時需要謹慎.第四個環節,數據庫中也可以有緩存, 比如說mysql的querycache.
那么也就是說在整個請求流程的任何一點,我們都可以加緩存.但是是所有的數據都可以放進緩存的嗎.當然不是,需要放進緩存的數據總是有一些特征的,要清楚的判斷數據是否可以被緩存,可以被怎樣緩存就必須要從數據的變化特征下手.
數據有哪些變化特征?最簡單的就是兩種,變和不變.我們都知道,不會變化的數據不需要每次都進行計算.問題是難道所有的數據理論上來講都會變化,變化是世界永恒的主題.也就是說我們把數據分為變和不變兩種是不對的,那么就讓我們再加一個條件:時間.那么我們就可以把數據特征總結為一段時間內變或者不變.那么根據這個數據特征,我們就可以在合適的位置和合適的緩存類型中緩存該數據.
3緩存有哪些屬性
從面向對象的角度來看,緩存就是一個對象,那么是對象,必然有屬性.那么下面我們來探討一下緩存有哪些屬性.以下列舉我們常用到的3個屬性.
(1) 命中率
命中率是指請求緩存次數和緩存返回正確結果次數的比例.比例越高,就證明緩存的使用率越高.
命中率問題是緩存中的一個非常重要的問題,我們都希望自己緩存的命中率能達到100%,但是往往事與愿違,而且緩存命中率是衡量緩存有效性的重要指標.
(2) 最大元素
緩存中可以存放得最大元素得數量,一旦緩存中元素數量超過這個值,那么將會起用緩存清空策略,根據不同的場景合理的設置最大元素值往往可以一定程度上提高緩存的命中率.從而更有效的時候緩存.
(3) 清空策略
1 FIFO ，first in first out ，最先進入緩存得數據在緩存空間不夠情況下(超出最大元素限制時)會被首先清理出去
2 LFU ， Less Frequently Used ，一直以來最少被使用的元素會被被清理掉。這就要求緩存的元素有一個hit 屬性，在緩存空間不夠得情況下,hit 值最小的將會被清出緩存。
2 LRU ，Least Recently Used ，最近最少使用的，緩存的元素有一個時間戳，當緩存容量滿了，而又需要騰出地方來緩存新的元素的時候，那么現有緩存元素中時間戳離當前時間最遠的元素將被清出緩存。
4緩存介質
從硬件介質上來將無非就是兩種,內存和硬盤(對應應用層的程序來講不用考慮寄存器等問題).但是往往我們不會從硬件上來劃分,一般的劃分方法是從技術上劃分,可以分成幾種,內存,硬盤文件.數據庫.
(1) 內存.將緩存放在內存中是最快的選擇,任何程序直接操作內存都比操作硬盤要快的多,但是如果你的數據要考慮到break down的問題,因為放在內存中的數據我們稱之為沒有持久話的數據,如果硬盤上沒有備份,機器down機之后,很難或者無法恢復.
(2) 硬盤.一般來說,很多緩存框架會結合使用內存和硬盤,比如給內存分配的空間有滿了之后,會讓用戶選擇把需要退出內存空間的數據持久化到硬盤.當然也選擇直接把數據放一份到硬盤(內存中一份,硬盤中一份,down機也不怕).也有其他的緩存是直接把數據放到硬盤上.
(3) 數據庫.說到數據庫,可能有的人會想,之前不是講到要減少數據庫查詢的次數,減少數據庫計算的壓力嗎,現在怎么又用數據庫作為緩存的介質了呢.這是因為數據庫又很多種類型,比如berkleydb,這種db不支持sql語句,沒有sql引擎,只是key和value的存儲結構,所以速度非常的快,在當代一般的pc上,每秒中十幾w次查詢都是沒有問題的(當然這個是根據業務特征來決定的,如果您訪問的數據在分布上是均勻的,那ahuaxuan可不能保證這個速度了).
除了緩存介質之外,ahuaxuan根據緩存和應用的耦合程度將其劃分為local cache和remote cache.
Local cache是指包含在應用之中的緩存組件.而remote cache指和應用解耦在應用之外的緩存組件.典型的local cache有ehcache,oscache,而remote cache有大名鼎鼎的memcached.
Localcache 最大的優點是應用和cache的時候是在同一個進程內部,請求緩存非常快速,完全不需要網絡開銷等.所以單應用,不需要集群或者集群情況下cache node不需要相互通知的情況下使用local cache比較合適.這也是java中ehcache和oscache這么流行的原因.
但是 Local cache是有一定的缺點的,一般這種緩存框架(比如java中的ehcache或者oscache)都是local cache.也就是跟著應用程序走的,多個應用程序無法直接共享緩存,應用集群的情況下這個問題更加明顯,當然也有的緩存組件提供了集群節點相互通知緩存更新的功能,但是由于這個是廣播,或者是環路更新,在緩存更新頻繁的情況下會導致網絡io開銷非常大,嚴重的時候會影響應用的正常運行.而且如果緩存中數據量較大得情況下使用localcache意味著每個應用都有一份這么大得緩存,著絕對是對內存的浪費.
所以這個情況下,往往我們會 選擇remote cache,比如memcached.這樣集群或者分布式的情況下各個應用都可以共享memcached中的數據,這些應用都通過socket和基于 tcp/ip協議上層的memcached協議直接連接到memcached,有一個app更新了memcached中的值,所有的應用都能拿到最新的值.雖然這個時候多了很多了網絡上的開銷,但是往往這種方案要比localcache廣播或環路更新cache節點要普遍的多,而且性能也比后者高.由于數據只需要保存一份,所以也提高了內存的使用率.
通過以上分析可以看出,不管是local cache,還是remote cache在緩存領域都有自己的一席之地,所以ahuaxuan建議在選擇或者使用緩存時一定要根據緩存的特征和我們的業務場景準確判斷使用何種緩存.這樣才能充分發揮緩存的功能.
Ahuaxuan 認為,緩存的使用是架構師的必備技能,好的架構師能夠根據數據的類型,業務的場景來準確的判斷出使用何種類型的緩存,并且如何使用這種類型的緩存.在緩存的世界里也沒有銀彈,目前還沒有一種緩存可以解決任何的業務場景或者數據類型,如果這種技術出現了,那架構師就又更不值錢了.呵呵.
OSCache
OSCache是個一個廣泛采用的高性能的J2EE緩存框架，OSCache能用于任何Java應用程序的普通的緩存解決方案。
OSCache有以下特點：
緩存任何對象，你可以不受限制的緩存部分jsp頁面或HTTP請求，任何java對象都可以緩存。
擁有全面的API--OSCache API給你全面的程序來控制所有的OSCache特性。
永久緩存--緩存能隨意的寫入硬盤，因此允許昂貴的創建（expensive-to-create）數據來保持緩存，甚至能讓應用重啟。
支持集群--集群緩存數據能被單個的進行參數配置，不需要修改代碼。
緩存記錄的過期--你可以有最大限度的控制緩存對象的過期，包括可插入式的刷新策略（如果默認性能不需要時）。
官方網站 http://www.opensymphony.com/oscache/
Java Caching System
JSC(Java Caching System)是一個用分布式的緩存系統，是基于服務器的java應用程序。它是通過提供管理各種動態緩存數據來加速動態web應用。
JCS和其他緩存系統一樣，也是一個用于高速讀取，低速寫入的應用程序。
動態內容和報表系統能夠獲得更好的性能。
如果一個網站，有重復的網站結構，使用間歇性更新方式的數據庫（而不是連續不斷的更新數據庫），被重復搜索出相同結果的，就能夠通過執行緩存方式改進其性能和伸縮性。
官方網站 http://jakarta.apache.org/turbine/jcs/
EHCache
EHCache 是一個純java的在進程中的緩存，它具有以下特性：快速，簡單，為Hibernate2.1充當可插入的緩存，最小的依賴性，全面的文檔和測試。
官方網站 http://ehcache.sourceforge.net/
JCache
JCache是個開源程序，正在努力成為JSR-107開源規范，JSR-107規范已經很多年沒改變了。這個版本仍然是構建在最初的功能定義上。
官方網站 http://jcache.sourceforge.net/
ShiftOne
ShiftOne Java Object Cache是一個執行一系列嚴格的對象緩存策略的Java lib，就像一個輕量級的配置緩存工作狀態的框架。
官方網站 http://jocache.sourceforge.net/
SwarmCache
SwarmCache是一個簡單且有效的分布式緩存，它使用IP multicast與同一個局域網的其他主機進行通訊，是特別為集群和數據驅動web應用程序而設計的。SwarmCache能夠讓典型的讀操作大大超過寫操作的這類應用提供更好的性能支持。
SwarmCache使用JavaGroups來管理從屬關系和分布式緩存的通訊。
官方網站 http://swarmcache.sourceforge.net
TreeCache / JBossCache
JBossCache是一個復制的事務處理緩存，它允許你緩存企業級應用數據來更好的改善性能。緩存數據被自動復制，讓你輕松進行JBoss服務器之間的集群工作。JBossCache能夠通過JBoss應用服務或其他J2EE容器來運行一個MBean服務，當然，它也能獨立運行。
JBossCache包括兩個模塊：TreeCache和TreeCacheAOP。
TreeCache --是一個樹形結構復制的事務處理緩存。
TreeCacheAOP --是一個“面向對象”緩存，它使用AOP來動態管理POJO(Plain Old Java Objects)
注：AOP是OOP的延續，是Aspect Oriented Programming的縮寫，意思是面向方面編程。
官方網站 http://www.jboss.org/products/jbosscache
WhirlyCache
Whirlycache是一個快速的、可配置的、存在于內存中的對象的緩存。它能夠通過緩存對象來加快網站或應用程序的速度，否則就必須通過查詢數據庫或其他代價較高的處理程序來建立。
首先你要理解OOP的思想,是
面向接口編程.
什么叫
面向接口編程呢?
假如你買了一個
多媒體設備,它給了你一個遙控,你想要知道的只是按什么按鈕,它會播放什么
而遙控里面是怎樣運行,還有屏幕里面怎么工作,你想知道嗎?
你完全不會去想了解.
那如果
多媒體設備需要更新,比如優化內部運行效率,
但是優化完了,遙控的按鈕不變,設備的所有操作方式都不變,按這個按鈕還是顯示相同的東西
那內部怎么變化你完全不需要在意.
這就是
面向接口編程.
無論類的內部怎么實現,它對外的接口不變,那它的使用方式就不會變
假設Main類要使用D類的一個draw的方法,
方法名叫 draw():void
不管draw里面是怎樣的,Main類里就是這樣用,
那么你就從這個接口出發,里面怎么實現是D類的事了,Main類只關心怎么用而已.
其他類要使用它,還是相同
這就大大減少了維護的成本.
因為如果D類出問題,Main類是完全不用改變的.
從上觀察,公開的接口越多,維護成本就越大.
維護就越麻煩.所以我們先寫接口,定死了公開的接口,
那維護就很方便,出錯也只是一個類的事,而不用同時修改多個協同類
http://www.cnblogs.com/doit8791/p/4093808.html
Spring框架里的bean，或者說組件，獲取實例的時候都是默認的單例模式，這是在多線程開發的時候要尤其注意的地方。
http://www.cnblogs.com/hoojo/archive/2011/05/05/2038101.html
單例模式的意思就是只有一個實例。單例模式確保某一個類只有一個實例，而且自行實例化并向整個系統提供這個實例。這個類稱為單例類。
當多用戶同時請求一個服務時，容器會給每一個請求分配一個線程，這是多個線程會并發執行該請求多對應的業務邏輯（成員方法），此時就要注意了，如果該處理邏輯中有對該單列狀態的修改（體現為該單列的成員屬性），則必須考慮線程同步問題
同步機制的比較 ThreadLocal和線程同步機制相比有什么優勢呢？ThreadLocal和線程同步機制都是為了解決多線程中相同變量的訪問沖突問題。
在同步機制中，通過對象的鎖機制保證同一時間只有一個線程訪問變量。這時該變量是多個線程共享的，使用同步機制要求程序慎密地分析什么時候對變量進行讀寫，什么時候需要鎖定某個對象，什么時候釋放對象鎖等繁雜的問題，程序設計和編寫難度相對較大。
而ThreadLocal則從另一個角度來解決多線程的并發訪問。ThreadLocal會為每一個線程提供一個獨立的變量副本，從而隔離了多個線程對數據的訪問沖突。因為每一個線程都擁有自己的變量副本，從而也就沒有必要對該變量進行同步了。ThreadLocal提供了線程安全的共享對象，在編寫多線程代碼時，可以把不安全的變量封裝進ThreadLocal。
由于ThreadLocal中可以持有任何類型的對象，低版本JDK所提供的get()返回的是Object對象，需要強制類型轉換。但JDK 5.0通過泛型很好的解決了這個問題，在一定程度地簡化ThreadLocal的使用
概括起來說，對于多線程資源共享的問題，同步機制采用了“以時間換空間”的方式，而ThreadLocal采用了“以空間換時間”的方式。前者僅提供一份變量，讓不同的線程排隊訪問，而后者為每一個線程都提供了一份變量，因此可以同時訪問而互不影響。
Spring使用ThreadLocal解決線程安全問題
我們知道在一般情況下，只有無狀態的Bean才可以在多線程環境下共享，在Spring中，絕大部分Bean都可以聲明為singleton作用域。就是因為Spring對一些Bean（如RequestContextHolder、TransactionSynchronizationManager、LocaleContextHolder等）中非線程安全狀態采用ThreadLocal進行處理，讓它們也成為線程安全的狀態，因為有狀態的Bean就可以在多線程中共享了。
一般的Web應用劃分為展現層、服務層和持久層三個層次，在不同的層中編寫對應的邏輯，下層通過接口向上層開放功能調用。在一般情況下，從接收請求到返回響應所經過的所有程序調用都同屬于一個線程
ThreadLocal是解決線程安全問題一個很好的思路，它通過為每個線程提供一個獨立的變量副本解決了變量并發訪問的沖突問題。在很多情況下，ThreadLocal比直接使用synchronized同步機制解決線程安全問題更簡單，更方便，且結果程序擁有更高的并發性。
如果你的代碼所在的進程中有多個線程在同時運行，而這些線程可能會同時運行這段代碼。如果每次運行結果和單線程運行的結果是一樣的，而且其他的變量的值也和預期的是一樣的，就是線程安全的。 或者說:一個類或者程序所提供的接口對于線程來說是原子操作或者多個線程之間的切換不會導致該接口的執行結果存在二義性,也就是說我們不用考慮同步的問題。 線程安全問題都是由全局變量及靜態變量引起的。
若每個線程中對全局變量、靜態變量只有讀操作，而無寫操作，一般來說，這個全局變量是線程安全的；若有多個線程同時執行寫操作，一般都需要考慮線程同步，否則就可能影響線程安全。
1） 常量始終是線程安全的，因為只存在讀操作。
2）每次調用方法前都新建一個實例是線程安全的，因為不會訪問共享的資源。
3）局部變量是線程安全的。因為每執行一個方法，都會在獨立的空間創建局部變量，它不是共享的資源。局部變量包括方法的參數變量和方法內變量。
有狀態就是有數據存儲功能。有狀態對象(Stateful Bean)，就是有實例變量的對象 ，可以保存數據，是非線程安全的。在不同方法調用間不保留任何狀態。
無狀態就是一次操作，不能保存數據。無狀態對象(Stateless Bean)，就是沒有實例變量的對象 .不能保存數據，是不變類，是線程安全的。
有狀態對象:
無狀態的Bean適合用不變模式，技術就是單例模式，這樣可以共享實例，提高性能。有狀態的Bean，多線程環境下不安全，那么適合用Prototype原型模式。Prototype: 每次對bean的請求都會創建一個新的bean實例。
Struts2默認的實現是Prototype模式。也就是每個請求都新生成一個Action實例，所以不存在線程安全問題。需要注意的是，如果由Spring管理action的生命周期， scope要配成prototype作用域。
二、線程安全案例：
SimpleDateFormat(下面簡稱sdf)類內部有一個Calendar對象引用,它用來儲存和這個sdf相關的日期信息,例如sdf.parse(dateStr), sdf.format(date) 諸如此類的方法參數傳入的日期相關String, Date等等, 都是交友Calendar引用來儲存的.這樣就會導致一個問題,如果你的sdf是個static的, 那么多個thread 之間就會共享這個sdf, 同時也是共享這個Calendar引用, 并且, 觀察 sdf.parse() 方法,你會發現有如下的調用:
Date parse() {
calendar.clear(); // 清理calendar
... // 執行一些操作, 設置 calendar 的日期什么的
calendar.getTime(); // 獲取calendar的時間
}
這里會導致的問題就是, 如果 線程A 調用了 sdf.parse(), 并且進行了 calendar.clear()后還未執行calendar.getTime()的時候,線程B又調用了sdf.parse(), 這時候線程B也執行了sdf.clear()方法, 這樣就導致線程A的的calendar數據被清空了(實際上A,B的同時被清空了). 又或者當 A 執行了calendar.clear() 后被掛起, 這時候B 開始調用sdf.parse()并順利i結束, 這樣 A 的 calendar內存儲的的date 變成了后來B設置的calendar的date
這個問題背后隱藏著一個更為重要的問題--無狀態：無狀態方法的好處之一，就是它在各種環境下，都可以安全的調用。衡量一個方法是否是有狀態的，就看它是否改動了其它的東西，比如全局變量，比如實例的字段。format方法在運行過程中改動了SimpleDateFormat的calendar字段，所以，它是有狀態的。
這也同時提醒我們在開發和設計系統的時候注意下一下三點:
1.自己寫公用類的時候，要對多線程調用情況下的后果在注釋里進行明確說明
2.對線程環境下，對每一個共享的可變變量都要注意其線程安全性
3.我們的類和方法在做設計的時候，要盡量設計成無狀態的
三.解決辦法
1.需要的時候創建新實例：
說明：在需要用到SimpleDateFormat 的地方新建一個實例，不管什么時候，將有線程安全問題的對象由共享變為局部私有都能避免多線程問題，不過也加重了創建對象的負擔。在一般情況下，這樣其實對性能影響比不是很明顯的。
2.使用同步：同步SimpleDateFormat對象
public class DateSyncUtil {
private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static String formatDate(Date date)throws ParseException{
synchronized(sdf){
return sdf.format(date);
}
}
public static Date parse(String strDate) throws ParseException{
synchronized(sdf){
return sdf.parse(strDate);
}
}
}
說明：當線程較多時，當一個線程調用該方法時，其他想要調用此方法的線程就要block，多線程并發量大的時候會對性能有一定的影響。
3.使用ThreadLocal：
public class ConcurrentDateUtil {
private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
}
};
public static Date parse(String dateStr) throws ParseException {
return threadLocal.get().parse(dateStr);
}
public static String format(Date date) {
return threadLocal.get().format(date);
}
}
或
public class ThreadLocalDateUtil {
private static final String date_format = "yyyy-MM-dd HH:mm:ss";
private static ThreadLocal<DateFormat> threadLocal = new ThreadLocal<DateFormat>();
public static DateFormat getDateFormat()
{
DateFormat df = threadLocal.get();
if(df==null){
df = new SimpleDateFormat(date_format);
threadLocal.set(df);
}
return df;
}
public static String formatDate(Date date) throws ParseException {
return getDateFormat().format(date);
}
public static Date parse(String strDate) throws ParseException {
return getDateFormat().parse(strDate);
}
}
說明：使用ThreadLocal, 也是將共享變量變為獨享，線程獨享肯定能比方法獨享在并發環境中能減少不少創建對象的開銷。如果對性能要求比較高的情況下，一般推薦使用這種方法。
4.拋棄JDK，使用其他類庫中的時間格式化類：
1.使用Apache commons 里的FastDateFormat，宣稱是既快又線程安全的SimpleDateFormat, 可惜它只能對日期進行format, 不能對日期串進行解析。
2.使用Joda-Time類庫來處理時間相關問題
做一個簡單的壓力測試，方法一最慢，方法三最快，但是就算是最慢的方法一性能也不差，一般系統方法一和方法二就可以滿足，所以說在這個點很難成為你系統的瓶頸所在。從簡單的角度來說，建議使用方法一或者方法二，如果在必要的時候，追求那么一點性能提升的話，可以考慮用方法三，用ThreadLocal做緩存。
Joda-Time類庫對時間處理方式比較完美，建議使用。
一、filter基于filter接口中的doFilter回調函數，interceptor則基于Java本身的反射機制；
二、filter是依賴于servlet容器的，沒有servlet容器就無法回調doFilter方法，而interceptor與servlet無關；
三、filter的過濾范圍比interceptor大，filter除了過濾請求外通過通配符可以保護頁面、圖片、文件等，而interceptor只能過濾請求，只對action起作用，在action之前開始，在action完成后結束（如被攔截，不執行action）；
四、filter的過濾一般在加載的時候在init方法聲明，而interceptor可以通過在xml聲明是guest請求還是user請求來辨別是否過濾；
五、interceptor可以訪問action上下文、值棧里的對象，而filter不能；
六、在action的生命周期中，攔截器可以被多次調用，而過濾器只能在容器初始化時被調用一次
loginit
com.cenin.util.servlet.LogInit
log4jConfig
/WEB-INF/classes/log4j.properties
1
mail.mymail.cn
webmaster
password
true
!-- 天氣預報的定時器 TianQiUtilTask 繼承TimerTask，實現run功能-->
http://www.cnblogs.com/hoojo/archive/2011/05/05/2038101.html
package comz.autoupdatefile;
import java.util.Timer;
import java.util.TimerTask;
public class M {
public static void main(String[] args) {
// TODO todo.generated by zoer
Timer timer = new Timer();
timer.schedule(new MyTask(), 1000, 2000);
}
}
class MyTask extends TimerTask {
@Override
public void run() {
System.out.println("dddd");
}
}
這樣，就可以在1秒鐘之后開始執行mytask，每兩秒鐘執行一次。
當然，timer的功能也可以通過自己構造線程，然后在線程中用sleep來模擬停止一段時間，然后再執行某個動作。
其實，看一下timertask的源碼就立即可以知道，timertask就是實現了runnable接口的。也就是說，通過timer來間隔一段時間執行一個操作，也是通過一個線程來做到的。
1、EXP:
有三種主要的方式（完全、用戶、表）
1、完全：
EXP SYSTEM/MANAGER BUFFER=64000 FILE=C:\FULL.DMP FULL=Y
如果要執行完全導出，必須具有特殊的權限
2、用戶模式：
EXP SONIC/SONIC BUFFER=64000 FILE=C:\SONIC.DMP OWNER=SONIC
這樣用戶SONIC的所有對象被輸出到文件中。
3、表模式：
EXP SONIC/SONIC BUFFER=64000 FILE=C:\SONIC.DMP OWNER=SONIC TABLES=(SONIC)
這樣用戶SONIC的表SONIC就被導出