2007年12月12日
Java的內(nèi)存模型中Thread會(huì)附有自己的堆棧，寄存器，必要時(shí)需要和主存即heap之間同步。
可以使用Synchornized關(guān)鍵字和Concurrent包中的Lock可以保證線程互斥和可見性。
互斥性體現(xiàn)在類鎖或者對(duì)象鎖上，每個(gè)對(duì)象自身都包含一個(gè)監(jiān)視器，該監(jiān)視器是一個(gè)每次只能被一個(gè)線程所獲取進(jìn)入的臨界區(qū)，可以通過wait和notify來退出和準(zhǔn)入臨界區(qū)?？梢?/font>看出這是一個(gè)生產(chǎn)者-消費(fèi)者的模型。而Concurrent包中的Lock為了能夠獲得更好的性能和更好的擴(kuò)展性，以及不依賴于關(guān)鍵字的可讀代碼，自己實(shí)現(xiàn)了這樣一個(gè)生產(chǎn)消費(fèi)隊(duì)列，也就是AbstractQueuedSynchronizer，被稱為AQS的機(jī)制。每個(gè)Lock都內(nèi)置了一個(gè)AbstractQueuedSynchronizer。需要說明的是AbstractQueuedSynchronizer內(nèi)部實(shí)現(xiàn)采用了CAS機(jī)制，通過getState, setState, compareAndSetState訪問控制一個(gè)32bit int的形式進(jìn)行互斥。
那么可見性是如何保證的呢？
對(duì)于關(guān)鍵字的同步機(jī)制，其實(shí)可見性就是線程和主存之間的同步時(shí)機(jī)問題。共有4個(gè)時(shí)間點(diǎn)需要注意：
1 獲取或釋放類鎖/對(duì)象鎖的時(shí)候。Thread保證reload/flush全部變更
2 volatile就是flush on write或者reload on read
3 當(dāng)線程首次訪問共享變量時(shí)，可以得到最新的結(jié)果。
題外：所以在構(gòu)造方法中公布this時(shí)很危險(xiǎn)的。簡(jiǎn)單的說，就是構(gòu)造時(shí)不逃脫任何變量，不開啟新的線程，只做封裝。關(guān)于安全構(gòu)造，請(qǐng)參考
http://www.ibm.com/developerworks/cn/java/j-jtp0618/#resources
4 線程結(jié)束時(shí)，所有變更會(huì)寫回主存
關(guān)于Concurrent Lock如何實(shí)現(xiàn)可見性的問題，Doug Lea大俠，只在他的論文中提到，按照J(rèn)SR133，Unsafe在getState, setState, compareAndSetState時(shí)保證了線程的變量的可見性，不需要額外的volatile支持，至于具體這些native做了哪些magic就不得而知了，總之，最后的contract就是保證lock區(qū)間的共享變量可見性。開發(fā)團(tuán)隊(duì)被逼急了就這樣回答：
There seems to be a real reluctance to explain the dirty details. I think the question was definitely understood on the concurrent interest thread, and the answer is that synchronized and concurrent locking are intended to be interchangable in terms of memory semantics when implemented correctly. The answer to matfud's question seems to be "trust us.”
不過這個(gè)地方的確是開發(fā)團(tuán)隊(duì)給我們用戶迷惑的地方，在同樣應(yīng)用了CAS機(jī)制的Atomic類中，都內(nèi)嵌了volatile變量，但是再lock塊中，他告訴我們可以保證可見性。
感興趣的同學(xué)可以下面的兩個(gè)thread和Doug Lea的thesis：
http://altair.cs.oswego.edu/pipermail/concurrency-interest/2005-June/001587.html
http://forums.sun.com/thread.jspa?threadID=631014&start=15&tstart=0
http://gee.cs.oswego.edu/dl/papers/aqs.pdf
ThreadLocal是一種confinement，confinement和local及immutable都是線程安全的（如果JVM可信的話）。因?yàn)閷?duì)每個(gè)線程和value之間存在hash表，而線程數(shù)量未知，從表象來看ThreadLocal會(huì)存在內(nèi)存泄露，讀了代碼，發(fā)現(xiàn)實(shí)際上也可能會(huì)內(nèi)存泄露。
事實(shí)上每個(gè)Thread實(shí)例都具備一個(gè)ThreadLocal的map，以ThreadLocal Instance為key，以綁定的Object為Value。而這個(gè)map不是普通的map，它是在ThreadLocal中定義的，它和普通map的最大區(qū)別就是它的Entry是針對(duì)ThreadLocal弱引用的，即當(dāng)外部ThreadLocal引用為空時(shí)，map就可以把ThreadLocal交給GC回收，從而得到一個(gè)null的key。
這個(gè)threadlocal內(nèi)部的map在Thread實(shí)例內(nèi)部維護(hù)了ThreadLocal Instance和bind value之間的關(guān)系，這個(gè)map有threshold，當(dāng)超過threshold時(shí)，map會(huì)首先檢查內(nèi)部的ThreadLocal（前文說過，map是弱引用可以釋放）是否為null，如果存在null，那么釋放引用給gc，這樣保留了位置給新的線程。如果不存在slate threadlocal，那么double threshold。除此之外，還有兩個(gè)機(jī)會(huì)釋放掉已經(jīng)廢棄的threadlocal占用的內(nèi)存，一是當(dāng)hash算法得到的table index剛好是一個(gè)null key的threadlocal時(shí)，直接用新的threadlocal替換掉已經(jīng)廢棄的。另外每次在map中新建一個(gè)entry時(shí)（即沒有和用過的或未清理的entry命中時(shí)），會(huì)調(diào)用cleanSomeSlots來遍歷清理空間。此外，當(dāng)Thread本身銷毀時(shí)，這個(gè)map也一定被銷毀了（map在Thread之內(nèi)），這樣內(nèi)部所有綁定到該線程的ThreadLocal的Object Value因?yàn)闆]有引用繼續(xù)保持，所以被銷毀。
從上可以看出Java已經(jīng)充分考慮了時(shí)間和空間的權(quán)衡，但是因?yàn)橹脼閚ull的threadlocal對(duì)應(yīng)的Object Value無法及時(shí)回收。map只有到達(dá)threshold時(shí)或添加entry時(shí)才做檢查，不似gc是定時(shí)檢查，不過我們可以手工輪詢檢查，顯式調(diào)用map的remove方法，及時(shí)的清理廢棄的threadlocal內(nèi)存。需要說明的是，只要不往不用的threadlocal中放入大量數(shù)據(jù)，問題不大，畢竟還有回收的機(jī)制。
綜上，廢棄threadlocal占用的內(nèi)存會(huì)在3中情況下清理：
1 thread結(jié)束，那么與之相關(guān)的threadlocal value會(huì)被清理
2 GC后，thread.threadlocals(map) threshold超過最大值時(shí)，會(huì)清理
3 GC后，thread.threadlocals(map) 添加新的Entry時(shí)，hash算法沒有命中既有Entry時(shí)，會(huì)清理
那么何時(shí)會(huì)“內(nèi)存泄露”?當(dāng)Thread長(zhǎng)時(shí)間不結(jié)束，存在大量廢棄的ThreadLocal，而又不再添加新的ThreadLocal（或新添加的ThreadLocal恰好和一個(gè)廢棄ThreadLocal在map中命中）時(shí)。
文檔應(yīng)該包括兩大部分，一部分是清晰的代碼結(jié)構(gòu)和注釋，比如Concurrent API就是這樣，還有一部分是文字文檔，包括三個(gè)小部分：一是開發(fā)文檔，應(yīng)該講架構(gòu)和功能；二是索引文檔，詳細(xì)介紹功能和參數(shù)，三是用戶文檔，包括安裝和使用說明
文檔最困難的莫過于版本的一致性，當(dāng)軟件升級(jí)后，一些obsolete的內(nèi)容和新的feature很難同步。要是架構(gòu)發(fā)生了變化，那就更困難了。一般document team都不是太精于技術(shù)，所以也會(huì)產(chǎn)生一些問題。
只能說任何事物永遠(yuǎn)都有改進(jìn)的空間，但是同樣也永遠(yuǎn)沒有達(dá)到完美的程度
摘要: 1 根據(jù)cpu core數(shù)量確定selector數(shù)量
2 用一個(gè)selector服務(wù)accept，其他selector按照core-1分配線程數(shù)運(yùn)行
3 accept selector作為生產(chǎn)者把獲得的請(qǐng)求放入隊(duì)列
4 某個(gè)selector作為消費(fèi)者從blocking queue中取出請(qǐng)求socket channel，并向自己注冊(cè)
5 當(dāng)獲得read信號(hào)時(shí)，selector建立工作...
閱讀全文
多線程的優(yōu)點(diǎn)：
1 多核利用
2 為單個(gè)任務(wù)建模方便
3 異步處理不同事件，不必盲等
4 現(xiàn)代的UI也需要它
風(fēng)險(xiǎn)：
1 同步變量易錯(cuò)誤
2 因資源限制導(dǎo)致線程活躍性問題
3 因2導(dǎo)致的性能問題
用途：
框架，UI，Backend
線程安全的本質(zhì)是什么：
并非是線程和鎖，這些只是基礎(chǔ)結(jié)構(gòu)，本質(zhì)是如何控制共享變量訪問的狀態(tài)
什么是線程安全：
就是線程之間的執(zhí)行
還沒有發(fā)生錯(cuò)誤，就是沒有發(fā)生意外
一個(gè)線程安全的類本身封裝了對(duì)類內(nèi)部方法和變量的異步請(qǐng)求，調(diào)用方無需考慮線程安全問題
無狀態(tài)的變量總是線程安全的
原子性：
完整執(zhí)行的單元，如不加鎖控制，則會(huì)發(fā)生競(jìng)態(tài)條件，如不加鎖的懶漢單例模式，或者復(fù)合操作。
鎖，內(nèi)在鎖，重入：
利用synchronized關(guān)鍵字控制訪問單元，同一線程可以重入鎖內(nèi)部，避免了面向?qū)ο螽a(chǎn)生的問題。同一變量的所有出現(xiàn)場(chǎng)合應(yīng)該使用同一個(gè)鎖來控制。synchronized(lock)。
即使所有方法都用synchronized控制也不能保證線程安全，它可能在調(diào)用時(shí)編程復(fù)合操作。
活躍性和性能問題：
過大的粒度會(huì)導(dǎo)致這個(gè)問題，用鎖進(jìn)行異步控制，導(dǎo)致了線程的順序執(zhí)行。
簡(jiǎn)單和性能是一對(duì)矛盾，需要適當(dāng)?shù)娜∩?。不能在沒有考慮成熟的情況下，為了性能去犧牲簡(jiǎn)潔性。
要盡量避免耗時(shí)操作，IO和網(wǎng)絡(luò)操作中使用鎖
Store包含兩個(gè)數(shù)據(jù)緩存 - snapshot和data，grid，combo等控件的顯示全部基于data，而snapshot是數(shù)據(jù)的完整緩存，當(dāng)首次應(yīng)用過濾器時(shí)，snapshot從data中備份數(shù)據(jù)，當(dāng)應(yīng)用過濾器時(shí)，filter從snapshot獲取一份完整的數(shù)據(jù)，并在其中進(jìn)行過濾，過濾后的結(jié)果形成了data并傳遞給展示，及data總是過濾后的數(shù)據(jù)，而snapshot總是完整的數(shù)據(jù)，不過看名字讓人誤以為它們的作用正好相反。
相應(yīng)地，當(dāng)進(jìn)行store的增刪改時(shí)，要同時(shí)維護(hù)兩個(gè)緩存。
問題
Store包含兩個(gè)增加Record的方法，即insert和add，其中的insert沒有更新snapshot所以當(dāng)重新應(yīng)用filter時(shí)，即data被重新定義時(shí)，在data中使用insert新增的記錄是無效的。
解決方法
用add不要用insert，如果用insert，記得把數(shù)據(jù)寫進(jìn)snapshot: store.snapshot.addAll(records)
摘要: 在Extjs中構(gòu)造N級(jí)聯(lián)動(dòng)下拉的麻煩不少，需定制下拉數(shù)據(jù)并設(shè)定響應(yīng)事件。通過對(duì)Combo集合的封裝，無需自己配置Combo，只需設(shè)定數(shù)據(jù)和關(guān)聯(lián)層級(jí)，即可自動(dòng)構(gòu)造出一組支持正向和逆向過濾的聯(lián)動(dòng)下拉并獲取其中某一個(gè)的實(shí)例。
如：
數(shù)據(jù)：
Ext.test = {};
Ext.test.lcbdata&nb...
閱讀全文
目前主流的SSH開發(fā)架構(gòu)中，為減輕開發(fā)者工作，便于管理開發(fā)過程，往往用到一些公共代碼和組件，或者采用了基于模版的代碼生成機(jī)制，對(duì)于后臺(tái)的DAO，Service等因?yàn)榧軜?gòu)決定，代碼生成必不可少，但是在前端頁(yè)面的實(shí)現(xiàn)上，卻可以有兩種不同的思路，一種是把配置信息直接封裝成更高級(jí)別的組建，一種是進(jìn)行代碼生成。請(qǐng)大家討論一下這兩種方案的優(yōu)劣，這里先拋磚引玉了。
相同點(diǎn)：
配置信息：XML OR 數(shù)據(jù)庫(kù)
控件化：
優(yōu)點(diǎn)：
1 易于添加公共功能
2 修改配置數(shù)據(jù)直接生效
3 代碼結(jié)構(gòu)清晰，對(duì)開發(fā)者友好
缺點(diǎn)：
1 重組內(nèi)存中對(duì)象結(jié)構(gòu)，性能沒有代碼生成好（但渲染時(shí)間相同）
2 僅能控制組件自身封裝的配置，不支持個(gè)性化修改，如果配置文件不支持的參數(shù)，則控件不支持
3 必須保證每個(gè)控件一個(gè)配置
代碼生成：
優(yōu)點(diǎn)：
1 性能較好
2 易于定制內(nèi)容
3 可以只配置一個(gè)模版，然后做出多個(gè)簡(jiǎn)單的修改
缺點(diǎn)：
1 不能針對(duì)多個(gè)頁(yè)面同時(shí)添加公共功能
2 業(yè)務(wù)修改需要重新生成代碼
3 開發(fā)者需要修改自動(dòng)生成的代碼，并需要了解一些底層的實(shí)現(xiàn)結(jié)構(gòu)
=====================20091029
代碼生成并不能提高工作效率，尤其是針對(duì)復(fù)雜的富客戶端開發(fā)
開發(fā)組件可提提供一種有效的選項(xiàng)，但是在運(yùn)行效率和內(nèi)存處理上需要細(xì)心處理
最近在學(xué)習(xí)jBPM和Javascript，所以按照一些相關(guān)概念自己寫了下面的200行代碼的“工作流引擎”，工作流管理系統(tǒng)包含了流程定義，引擎，及應(yīng)用系統(tǒng)三個(gè)主要部分，下面的代碼實(shí)現(xiàn)了流程的分支合并，目前只支持一種環(huán)節(jié)上的遷移?？截惖?/span>html，雙擊就可以跑起來。
var workflowDef = {
start:{
fn:"begin", //對(duì)應(yīng)處理方法可以在內(nèi)部定義，也可以在外部定義
next:["task1","task2"]
},
end:"end",
tasks:[{
id:"task1",
fn:function(){
alert("執(zhí)行任務(wù)一");
},
before:function(){
alert("執(zhí)行任務(wù)一前");
},
after:function(){
alert("執(zhí)行任務(wù)一后");
},
next:["task4","task5"]
},{
id:"task2",
fn:function(){
alert("執(zhí)行任務(wù)二");
},
before:function(){
alert("執(zhí)行任務(wù)二前");
},
after:function(){
alert("執(zhí)行任務(wù)二后");
},
next:["task3"]
},{
id:"task3",
fn:function(){
alert("執(zhí)行任務(wù)三");
},
before:function(){
alert("執(zhí)行任務(wù)三前");
},
after:function(){
alert("執(zhí)行任務(wù)三后");
},
//定義合并的數(shù)量
merge: 3,
next:"EOWF"
},{
id:"task4",
fn:function(){
alert("執(zhí)行任務(wù)四");
},
before:function(){
alert("執(zhí)行任務(wù)四前");
},
after:function(){
alert("執(zhí)行任務(wù)四后");
},
next:["task3"]
},{
id:"task5",
fn:function(){
alert("執(zhí)行任務(wù)五");
},
before:function(){
alert("執(zhí)行任務(wù)五前");
},
after:function(){
alert("執(zhí)行任務(wù)五后");
},
next:["task3"]
}]
}
//////////定義引擎////////////
Yi = {};
Yi.Utils = {};
Yi.Utils.execute = function(o){
if(typeof o != 'function')
eval(o)();
else
o();
}
//工作流類
Yi.Workflow = function(workflowDef){
this.def = workflowDef;
this.tasks = this.def.tasks;
}
//public按照環(huán)節(jié)id查找查找
Yi.Workflow.prototype.findTask = function(taskId){
for(var i=0;i<this.tasks.length;i++){
if(this.tasks[i].id == taskId)
return this.tasks[i];
}
}
//public啟動(dòng)工作流
Yi.Workflow.prototype.start = function(){
this.currentTasks = [];
Yi.Utils.execute(this.def.start.fn);
for(var i=0;i<this.def.start.next.length;i++){
this.currentTasks[i] = this.findTask(this.def.start.next[i]);
Yi.Utils.execute(this.currentTasks[i].before);
}
}
//private
Yi.Workflow.prototype.findCurrentTaskById = function(taskId){
for(var i=0;i<this.currentTasks.length;i++){
if(this.currentTasks[i].id == taskId)
return this.currentTasks[i];
}
return null;
}
//private
Yi.Workflow.prototype.removeFromCurrentTasks = function(task){
var temp = [];
for(var i=0;i<this.currentTasks.length;i++){
if(!(this.currentTasks[i] == task))
temp.push(this.currentTasks[i]);
}
this.currentTasks = temp;
temp = null;
}
//public觸發(fā)當(dāng)前環(huán)節(jié)
Yi.Workflow.prototype.signal = function(taskId){
//只處理當(dāng)前活動(dòng)環(huán)節(jié)
var task = this.findCurrentTaskById(taskId);
if(task == null){
alert("工作流未流轉(zhuǎn)到此環(huán)節(jié)!");
return;
}
//對(duì)于合并的處理
if(task.merge != undefined){
if(task.merge != 0){
alert("工作流流轉(zhuǎn)條件不充分!");
return;
}else{
Yi.Utils.execute(task.before);
}
}
//觸發(fā)當(dāng)前環(huán)節(jié)
Yi.Utils.execute(task.fn);
//觸發(fā)后動(dòng)作
Yi.Utils.execute(task.after);
//下一步如果工作流結(jié)束
if(task.next === "EOWF"){
Yi.Utils.execute(this.def.end);
delete this.currentTasks;
return;
}
//遍歷下一步環(huán)節(jié)
this.removeFromCurrentTasks(task);
for(var i=0;i<task.next.length;i++){
var tempTask = this.findTask(task.next[i]);
if(!tempTask.inCurrentTasks)
this.currentTasks.push(tempTask);
if(tempTask.merge != undefined){
tempTask.merge--;
tempTask.inCurrentTasks = true;
}
else
Yi.Utils.execute(tempTask.before);
}
}
//public獲取當(dāng)前的活動(dòng)環(huán)節(jié)
Yi.Workflow.prototype.getCurrentTasks = function(){
return this.currentTasks;
}
//public獲取流程定義
Yi.Workflow.prototype.getDef = function(){
return this.def;
}
////////應(yīng)用系統(tǒng)///////////////
var wf = new Yi.Workflow(workflowDef);
alert("啟動(dòng)工作流");
wf.start();
alert("嘗試手工執(zhí)行任務(wù)3,返回工作流沒有流轉(zhuǎn)到這里");
wf.signal("task3");
alert("分支開始");
alert("手工執(zhí)行任務(wù)1");
wf.signal("task1");
alert("手工執(zhí)行任務(wù)2");
wf.signal("task2");
alert("手工執(zhí)行任務(wù)4");
wf.signal("task4");
alert("手工執(zhí)行任務(wù)5");
wf.signal("task5");
alert("手工執(zhí)行任務(wù)3");
wf.signal("task3");
function begin(){
alert("流程開始，該函數(shù)在外部定義");
}
function end(){
alert("流程結(jié)束");
}
1 對(duì)于類型是checkboxgroup的數(shù)據(jù)，數(shù)據(jù)庫(kù)中保存數(shù)據(jù)的格式是value1,value2...valueN，其中1~N的數(shù)據(jù)有可能不存在，如果選中則存在，最后拼接成一個(gè)串。
在Ext中，通過Record對(duì)象向FormPanel中的內(nèi)置對(duì)象BasicForm加載數(shù)據(jù)時(shí)，采用的是setValues方法，而setValues第一步要通過Record中定義的name使用findField方法找到表單元素，遺憾的是，繼承了Field的checkboxgroup組件并不能正確的通過getName返回自身引用，所以，需要對(duì)getName方法進(jìn)行重寫，此外，為了適應(yīng)我們采用的數(shù)據(jù)格式，對(duì)于該組件的setValue（被setValues調(diào)用）和getValue（獲取到已加工的數(shù)據(jù)，此事后話）也要進(jìn)行重寫。故而對(duì)于形如：
{
xtype: 'checkboxgroup',
name: 'biztype',
width: 220,
columns: 3,
fieldLabel: '業(yè)務(wù)類別',
items: [
{boxLabel: '類別1', inputValue: '01'},
{boxLabel: '類別2', inputValue: '02'},
{boxLabel: '類別3', inputValue: '03'},
{boxLabel: '類別4', inputValue: '04'}
]
}
的checkboxgroup定義，需重寫類如下：
Ext.override(Ext.form.CheckboxGroup,{
//在inputValue中找到定義的內(nèi)容后，設(shè)置到items里的各個(gè)checkbox中
setValue : function(value){
this.items.each(function(f){
if(value.indexOf(f.inputValue) != -1){
f.setValue(true);
}else{
f.setValue(false);
}
});
},
//以value1,value2的形式拼接group內(nèi)的值
getValue : function(){
var re = "";
this.items.each(function(f){
if(f.getValue() == true){
re += f.inputValue + ",";
}
});
return re.substr(0,re.length - 1);
},
//在Field類中定義的getName方法不符合CheckBoxGroup中默認(rèn)的定義，因此需要重寫該方法使其可以被BasicForm找到
getName : function(){
return this.name;
}
});
2 通過內(nèi)置對(duì)象basicForm的getValues方法可以獲取到一個(gè)form的完整json數(shù)據(jù)，但遺憾的事，這里取到的是dom的raw數(shù)據(jù)，類似emptyText的數(shù)據(jù)也會(huì)被返回，而Field的getValue方法不存在這個(gè)問題，所以如果想要返回一個(gè)非raw的json集合，可以給formpanel添加如下方法：
getJsonValue:function(){
var param = '{';
this.getForm().items.each(function(f){
var tmp = '"' + f.getName() + '":"' + f.getValue() + '",';
param += tmp;
});
param = param.substr(0,param.length - 1) + '}';
return param;
}
這個(gè)方法同樣適用于上面定義的checkboxgroup，如此就可以把前后臺(tái)的數(shù)據(jù)通過json統(tǒng)一起來了
摘要: 當(dāng)前的富客戶端可以包含兩部分：分別為JSP頁(yè)面和通過富客戶端js組件（如extjs）渲染的組件化窗口頁(yè)。針對(duì)這兩部分分別做如下處理：
對(duì)于JSP頁(yè)面的部分采用JSTL標(biāo)準(zhǔn)庫(kù)的fmt標(biāo)簽，如通過：
<fmt:message key="page.login.title"/>這樣的形式進(jìn)行展現(xiàn)，其中message對(duì)應(yīng)的文本在服務(wù)端配置，并在web.xml中配置資源文件的位置，也可以采用s...
閱讀全文
看此文前請(qǐng)保證jar包中有至少一個(gè)Main方法入口，及圖形化的界面。
并保證META-INF/MANIFEST文件中的Main-Class已經(jīng)指向之前實(shí)現(xiàn)的main方法入口。
最近硬盤壞了，于是重新安裝了OS，發(fā)現(xiàn)拷貝后的jdk或jre（未經(jīng)安裝的版本），不能打開jar文件執(zhí)行（jdk版本1.6_11），
于是在打開方式中指向了javaw程序，發(fā)現(xiàn)無效，并提示"cannot find main class", 與此同時(shí)windows把jar類型的文件關(guān)聯(lián)到了
指定的javaw程序上，上網(wǎng)找了一通，沒有人提及這個(gè)問題的解決辦法，而顯然這個(gè)問題又不是由開篇中提到的問題導(dǎo)致的。
于是在注冊(cè)表中當(dāng)前用戶配置中刪除了當(dāng)前jar類型的定義。但是重新嘗試后依然無效。
于是重新安裝了jdk，發(fā)現(xiàn)這次可以打開jar文件了，并且這次用來打開的程序從打開方式來看仍然是javaw。
比較注冊(cè)表中文件類型的定義，并沒有差別。從文件夾選項(xiàng) -> 文件類型來看終于看到了差別，
高級(jí)里面的open操作定義如下：
"C:\Program Files\Java\jre6\bin\javaw.exe" -jar "%1" %*
而如果我們自己選擇javaw，默認(rèn)的open操作是沒有 -jar參數(shù)的，必須手工加進(jìn)去。
我們知道java啟動(dòng)jar包的參數(shù)是 -jar，但是記得以前javaw是可以直接打開jar的，不知什么時(shí)候起也需要帶有-jar參數(shù)了。
所以對(duì)于一個(gè)拷貝的綠色jre只要修改一下open操作的定義就可以解決上面的問題了。
解決了上面的問題，又產(chǎn)生了新的問題，之前選擇打開的javaw程序在打開方式中丟不掉了，比較多余，這個(gè)可以在注冊(cè)表中修改
在HKEY_CLASSES_ROOT\Applications下面找到響應(yīng)的程序刪除就可以了，原來每次用一個(gè)程序打開一個(gè)類型的文件windows都會(huì)在
注冊(cè)表中這個(gè)地方留下相關(guān)的記錄
偶然間注意到一個(gè)困擾了我很久的問題，那就是如果我不通過Socket而通過應(yīng)用層的某種基于文本的協(xié)議，比如SOAP進(jìn)行通信的話，
如何傳遞二進(jìn)制的數(shù)據(jù)呢？現(xiàn)在SOA，Web Service等很火，應(yīng)該會(huì)遇到這種問題吧？
現(xiàn)在已知的方法可以通過Base64進(jìn)行編碼，其原理和方法見：
http://baike.baidu.com/view/469071.htm
這種方法采用了字節(jié)中的6位進(jìn)行文本轉(zhuǎn)換，并且在其他論壇上也看到了帖子說淘寶的搜索也采用了這種編碼方式進(jìn)行處理。
但是采用了5位進(jìn)行轉(zhuǎn)換。并且大膽地給出了5位轉(zhuǎn)碼的算法，見：
http://www.javaeye.com/topic/286240
不過這種5位的轉(zhuǎn)換會(huì)產(chǎn)生更多多余的字節(jié)，6位的轉(zhuǎn)碼充分利用了現(xiàn)今的可讀文本，可是5位卻沒有，因?yàn)?和8的最小公倍數(shù)是40，
所以當(dāng)每轉(zhuǎn)換40位即5個(gè)字節(jié)的二進(jìn)制數(shù)據(jù)需要8個(gè)字節(jié)來表示，這樣就多產(chǎn)生3個(gè)字節(jié)，浪費(fèi)的效率是3/5, 而6位轉(zhuǎn)碼浪費(fèi)的效率是
1/3。而且隨著字節(jié)增多，轉(zhuǎn)化效率也在下降?？梢姴捎?位轉(zhuǎn)碼是一種既浪費(fèi)空間，又浪費(fèi)效率的解決方案。在不增加url長(zhǎng)度的情況下充分提高效率，6位編碼是最佳的。如果可以任意的餓犧牲url長(zhǎng)度，
可以把0-9全部拿出來當(dāng)做標(biāo)記位，0-9不會(huì)單獨(dú)出現(xiàn)，這樣一共有10*26 + 26 = 286 種可能還不包括小寫字母，
此外還有=，+，-什么的至少256可以編碼8位的字節(jié)了，這樣處理效率就提高了。
現(xiàn)在把問題優(yōu)化一下，人類可讀無歧義的文本碼有0-9，A-Z,a-z共62個(gè)
設(shè)取出x個(gè)作為標(biāo)志位則(62-x) * x + (62 - x) >= 256
解這個(gè)二元一次方程得到:
3.366<=X<=57.634
考慮到編碼的文本長(zhǎng)度，取x的最小值，即 4
最優(yōu)解：
用0, 1, 2, 3做為標(biāo)志位
4-9，A-Z, a-z參與編碼并與標(biāo)志位配合實(shí)現(xiàn)8位字節(jié)的文本化
可以看到這種方法的轉(zhuǎn)碼效率會(huì)比較高，但是空間冗余大。
此外其實(shí)可用的文本不知62個(gè)，包括感嘆號(hào)等用上后補(bǔ)足64 = 2^6
它的高位是 00
那么只要再找到三個(gè)文本符保存其他三個(gè)高位01 10 11就可以了
這樣的轉(zhuǎn)碼空間可以更小一些。
想法還很不成熟，歡迎大家批評(píng)
摘要: 最近在學(xué)習(xí)JavaScript，發(fā)現(xiàn)不論是ext還是prototype都很推崇json這種通信協(xié)議的格式，但是這兩個(gè)框架都是比較偏前端的，和dwr不同，dwr是一個(gè)一站式的ajax框架，不僅提供了客戶端的工具方法，也包括服務(wù)端的配置和通信的處理。
而ext和prototype等僅僅設(shè)置好了json的接口并對(duì)ajax通信做了封裝，相對(duì)而言是一種比較“純粹”的AJAX實(shí)現(xiàn)，當(dāng)...
閱讀全文
學(xué)過軟件工程的都知道，軟件產(chǎn)品的生產(chǎn)周期是一個(gè)經(jīng)歷若干階段的漫長(zhǎng)過程，包括需求獲取 - 設(shè)計(jì) - 開發(fā) - 維護(hù)等等。
需求階段 - 總想考慮到所有的問題，或是一切按合同辦事。但在現(xiàn)實(shí)中根本不得能，因此很多公司開始提倡“隨需而變”的能力，希望快速的響應(yīng)用戶的需求變化
維護(hù)階段 - 總希望自己開發(fā)出來的東西一勞永逸，永遠(yuǎn)不要再產(chǎn)生任何麻煩，產(chǎn)生了麻煩也不要找到我。甚至有些項(xiàng)目組的人員開發(fā)出來一大堆不成熟的產(chǎn)品、項(xiàng)目后撒手不管，走人了事，毫無職業(yè)操守，亦是對(duì)自身行業(yè)聲譽(yù)（至少是國(guó)內(nèi)IT服務(wù)提供商聲譽(yù)）的一個(gè)打擊。真正的項(xiàng)目開發(fā)不應(yīng)該這樣，一定是非常易于維護(hù)的，能夠快速地找出問題的所在，或是新需求切入點(diǎn)的所在，然后解決
很明顯，前面提到的兩個(gè)問題都要也只能通過設(shè)計(jì)和開發(fā)來解決。問題來了，怎樣開發(fā)出的軟件才能快速地響應(yīng)需求，易于維護(hù)？可以有很多不相沖突的說法，比如解耦，比如通過POJO封裝數(shù)據(jù)等等。這些東西流行開來以后，很多人有疑問，為什么我的項(xiàng)目中一定要用這些框架？我不用這些框架也可以快速的開發(fā)出我要的功能，而且更加簡(jiǎn)單，等等。如果孤立地從設(shè)計(jì)和開發(fā)的角度看這些問題，這種說法并沒有錯(cuò)誤，但是如果從整個(gè)軟件開發(fā)的生命周期來看，則不是這樣。當(dāng)然，這里還有一個(gè)是否“過度設(shè)計(jì)”的trade-off在里面，不過那又是另一個(gè)話題了。
再說說各種各樣的平臺(tái)吧，它們和框架不同，軟件體系結(jié)構(gòu)中有一種架構(gòu)模型即層次模型，我們現(xiàn)在的TCP/IP協(xié)議棧即屬于這種模型，我們的軟件對(duì)于平臺(tái)產(chǎn)品的依賴是一種朝向穩(wěn)定的依賴，就好像我們?cè)谡{(diào)試代碼時(shí)往往不會(huì)去調(diào)試操作系統(tǒng)API的bug一樣，因此在開發(fā)這種平臺(tái)層次級(jí)別的產(chǎn)品時(shí)就沒有必要再去采用那些為了保障“企業(yè)應(yīng)用”Web軟件生命周期中所采用的方法了，完全可以用最基礎(chǔ)，最底層的手段。只要能夠做到高效、穩(wěn)定即可。因此，平臺(tái)中間件產(chǎn)品的開發(fā)必須和應(yīng)用軟件產(chǎn)品分開來看，雖然它們可能都在用Java這種編程語言。
本科讀書時(shí)，曾聽過離散數(shù)學(xué)老師一句很精彩的論斷：“只要能夠形式化的東西，就可以自動(dòng)化”?？墒墙裉煳也徽勲x散數(shù)學(xué)，倒想說說其他不相關(guān)的東西。
你一定聽到過“一流的企業(yè)賣標(biāo)準(zhǔn)，二流的企業(yè)賣品牌，三流的企業(yè)賣產(chǎn)品”。
什么是形式化？為什么形式化的東西就可以自動(dòng)化呢？撇開數(shù)學(xué)符號(hào)不談，對(duì)企業(yè)來說，形式化的東西可以是一些規(guī)章及做事的方法，生產(chǎn)產(chǎn)品的方法等等。為什么人民幣稍一升值，中國(guó)的中小制造型企業(yè)就要痛苦不堪？因?yàn)槲覀兠考葲]有品牌，更沒有標(biāo)準(zhǔn)，拿生產(chǎn)DVD機(jī)為例，最初的90年代生產(chǎn)DVD機(jī)賣到歐美很賺，可是現(xiàn)在據(jù)說不賠錢就不錯(cuò)了，因?yàn)橐U納一大筆的專利費(fèi)。中國(guó)的大多數(shù)企業(yè)處在整個(gè)產(chǎn)業(yè)鏈的最下端，所得的利潤(rùn)的大多數(shù)被其他企業(yè)剝奪了，因?yàn)槲覀冇玫氖莿e人的品牌，別人的標(biāo)準(zhǔn)。我們的公司在全球經(jīng)濟(jì)中處于“民工”的境地。
回到我們的問題中來，一流企業(yè)所做的標(biāo)準(zhǔn)，是生產(chǎn)一種產(chǎn)品的方式和規(guī)約，這一層面是抽象世界的最高層次，無法對(duì)這層抽象的產(chǎn)生進(jìn)行形式化，所以是一種創(chuàng)造性的勞動(dòng)；二流企業(yè)所賣的品牌是對(duì)一種產(chǎn)品具體生產(chǎn)方法的規(guī)約，通過“模板方法模式”的應(yīng)用，這一層次的抽象的模板可以從上一個(gè)層次的形式化中自動(dòng)化，然后只需形式化具體的操作細(xì)節(jié)，對(duì)于生產(chǎn)細(xì)節(jié)的形式化，也需要一定的創(chuàng)造性的勞動(dòng)；三流的企業(yè)是一部機(jī)器，因?yàn)榈酱藶橹挂磺械臇|西都已經(jīng)形式化了，只需要有時(shí)間和精力的機(jī)器去自動(dòng)完成而已。
讓我們好好想想在一個(gè)知識(shí)經(jīng)濟(jì)的社會(huì)里，什么事物是創(chuàng)造性的，是只能被形式化而不能被自動(dòng)化的。因?yàn)橹挥腥祟惖膭?chuàng)造性思想不能被機(jī)器所取代，這也是為什么機(jī)器人無法取代人類的原因。
80年代出生的人應(yīng)該記得歷史教科書中的論述，工業(yè)革命時(shí)，一些工人去砸毀機(jī)器，覺得這些機(jī)器剝奪了他們的工作。如果有一天，老板突然來告訴您：你可以離開了，請(qǐng)不要沮喪和懊悔，因?yàn)槟缭撘庾R(shí)到您其實(shí)就是一部機(jī)器。當(dāng)然為了防止上面悲劇的發(fā)生，早點(diǎn)去從事有創(chuàng)造性的工作吧，停止對(duì)于各種軟件自動(dòng)化輔助工具的抱怨和擔(dān)憂，勇敢地迎接明天。
還記得小時(shí)候?？吹碾娪啊渡癖蕖钒?！
偶然間看到下面有一個(gè)網(wǎng)友慨嘆普元的強(qiáng)大，而開發(fā)人員的渺小。
小弟剛剛參加工作，也在項(xiàng)目中接觸到了普元的EOS。普元的這個(gè)東西怎么說呢，就是亂用XML然后Spring沒做好就變成那個(gè)樣子的，同時(shí)失去了類型的表述，一部機(jī)器要進(jìn)行裝配需要組件和零件，軟件應(yīng)該自上而下，分而治之，這是上個(gè)世紀(jì)70年代，學(xué)者們就達(dá)成的共識(shí)，所以關(guān)于“銀彈”神話的唯一結(jié)論就是——“沒有銀彈”。
為什么說EOS是沒有做好的Spring？
Spring簡(jiǎn)化了對(duì)象的裝配，強(qiáng)調(diào)重用，是建立在面向?qū)ο蠡A(chǔ)上的，是建立在敏捷測(cè)試基礎(chǔ)上的，是建立在強(qiáng)類型基礎(chǔ)上的；
而EOS則是建立在面向過程的基礎(chǔ)上的，建立在不可測(cè)試的基礎(chǔ)上的，建立在毫無類型基礎(chǔ)上的（全是String）
然而EOS也有很多的優(yōu)點(diǎn)（據(jù)小弟不完全發(fā)現(xiàn)）：
1）EOS固化的開發(fā)流程強(qiáng)制一個(gè)team從一種易于維護(hù)的結(jié)構(gòu)組織Web，包括頁(yè)面，表示層，邏輯層等等。否則的話就需要一個(gè)架構(gòu)師來做出規(guī)約，但仍不易于管理；
2）EOS的畫圖功能讓人耳目一新，從“代碼即文檔”的哲學(xué)出發(fā)，這些畫圖很好地詮釋了代碼表述的內(nèi)容和結(jié)構(gòu)，給程序的維護(hù)帶來便利。
3）相對(duì)于OO和J2EE傳統(tǒng)開發(fā)，EOS易于上手，學(xué)習(xí)曲線較短。但是這一點(diǎn)有爭(zhēng)議，EOS的知識(shí)不具備通用性。
綜上，根據(jù)2-8的關(guān)系法則，在某些領(lǐng)域EOS的確有其優(yōu)點(diǎn)，但是認(rèn)為EOS完全“解放”了程序員，則是不負(fù)責(zé)任的說法。
這只是我的個(gè)人看法，歡迎大家就此話題討論。
聯(lián)合國(guó)是國(guó)家間的標(biāo)準(zhǔn)化組織，可惜一超多強(qiáng)們只把它當(dāng)作是一個(gè)道具，需要時(shí)拿來用一下，不需要時(shí)完全可以踢到一邊。
歷史上，每個(gè)朝代都認(rèn)識(shí)到失敗的教訓(xùn)，卻最終都迎來了相似的結(jié)局。
有人說，軟件行業(yè)是一個(gè)天生的壟斷行業(yè)，其特質(zhì)是，產(chǎn)品研發(fā)的過程異常的復(fù)雜，但產(chǎn)品一旦出爐，就可以瘋狂而不計(jì)成本地生產(chǎn)。只有NRE Cost，眼下的軟件行業(yè)也出現(xiàn)了群雄逐鹿的場(chǎng)面，上游產(chǎn)業(yè)被幾家大公司所瓜分，這些大公司如果能互相牽制，則會(huì)坐在一起，成立一個(gè)組織。如果一家獨(dú)大，則我行我素，稱王稱霸。
看看他們的一路成長(zhǎng)：
初始：
他們想占有你，最初都會(huì)很乖。就像女孩在成為家庭主婦之前總能收到男孩的禮物。
成長(zhǎng)：
大公司們也漸漸從規(guī)范的參與者，變成規(guī)范+的樹立者，比如IE，Office，再比如Oracle的特性等等。
稱霸：
市場(chǎng)占有的差不多了，可以不顧客戶的意志做自己喜歡的事情，反正你已經(jīng)離不開我。
消亡：
客戶們?cè)孤曒d道，新的“符合規(guī)范”或簡(jiǎn)潔明了的產(chǎn)品出現(xiàn)市場(chǎng)。
希望這些大軟件廠商們能夠吸取教訓(xùn)，也希望小軟件廠商們將來不要走入歷史的怪圈。
在遠(yuǎn)古時(shí)期人們靠結(jié)繩紀(jì)事，據(jù)說美洲的瑪雅文明在覆滅之前都一直沒有自己的文字，而采用這種古老的方法。
后來我們的祖先發(fā)明了文字，在竹簡(jiǎn)上，布帛上書寫文字，竹簡(jiǎn)和布帛就是信息的載體，這樣的載體造價(jià)不菲，所以我們的文言和白話就有這么大的差距，留下的論語也要微言大義。再后來我們的祖先發(fā)明了紙張，嚴(yán)重地降低了承載信息的開銷，于是人類的文明得以更好地記錄和更快地發(fā)展。今天，我們的信息載體又有了新的變化，一張光盤，一個(gè)硬盤都可以承載無數(shù)的學(xué)問。
信息有了載體，隨之產(chǎn)生了信息管理的問題：
如何對(duì)信息進(jìn)行增刪改查的操作？如何處理附加在信息上的工作流？如何管理權(quán)限？
在IT系統(tǒng)出現(xiàn)之前，人們通過圖書館管理圖書，通過搬運(yùn)工進(jìn)行信息流動(dòng)，通過鑰匙和鎖頭管理權(quán)限。
在IT系統(tǒng)出現(xiàn)之后，人類可以通過計(jì)算機(jī)來完成這些操作。這其中數(shù)據(jù)庫(kù)系統(tǒng)，工作流系統(tǒng)幫了我們大忙。
IT系統(tǒng)處理信息的過程是：
多樣式的文檔（抽象為XML）-> 內(nèi)存數(shù)據(jù) -> 持久化（文件數(shù)據(jù)庫(kù)）->內(nèi)存數(shù)據(jù) -> 多樣式的文檔(抽象為XML)
我們讓用戶在我們?cè)O(shè)定的UI窗口進(jìn)行輸入，然后通過報(bào)表的形式產(chǎn)生各種各樣的輸出。中間一個(gè)步驟一個(gè)步驟，一個(gè)環(huán)節(jié)一個(gè)環(huán)節(jié)的走下去。
這其中，我們把很大一部分精力消耗在，如何讓用戶舒服的輸入，和產(chǎn)生用戶所需要的輸出上。
于是人們就要思考，難道不可以直接編輯一種全世界認(rèn)可的文檔形式（大家現(xiàn)在正在和MS爭(zhēng)吵的東西）通過網(wǎng)絡(luò)流轉(zhuǎn)，然后獲得結(jié)果嗎？為什么要從程序員的角度加給用戶數(shù)據(jù)庫(kù)，工作流，錄入界面這些繁雜的東西？
從這點(diǎn)意義上說，我推崇Sharepoint或者Google sites。
就拿google docs來說吧，在線編輯word，每個(gè)環(huán)節(jié)通過分享的形式進(jìn)行編輯，授權(quán)這部分可以通過歷史記錄來找到，隨時(shí)恢復(fù)到歷史版本，因此也不怕誤操作和無權(quán)限操作，真正的所見即所得，支持50人同時(shí)在線編輯。這難道不是OA的殺手級(jí)應(yīng)用嗎？
學(xué)習(xí)這些框架技術(shù)，我覺得歸根結(jié)底就是做什么的，為什么做，如何做
前人說讀書有三個(gè)層次，我看這大概可以總結(jié)為是新的三個(gè)層次：）
因?yàn)闆]有搞清楚為什么要用，就會(huì)誤用，用了還不如沒用。其實(shí)我覺得學(xué)spring讀讀rod那個(gè)原著挺好的，比單純學(xué)spring有幫助，最好自己有體會(huì)。比如你開發(fā)網(wǎng)站很熟練了，自然就知道為什么要用spring了。等完全領(lǐng)會(huì)了他那兩本書后，再讀讀他們的reference book應(yīng)該差不多了。
這個(gè)過程其實(shí)就是做什么->為什么->怎么做的過程
最近在研究關(guān)于系統(tǒng)的基于日志的故障恢復(fù)，無意間在網(wǎng)上發(fā)現(xiàn)一篇論文中對(duì)于系統(tǒng)日志模型的精彩論述，翻譯過來并附上我的思路：
『
一個(gè)系統(tǒng)是一個(gè)具有明顯的邊界的實(shí)體，它根據(jù)一定的輸入，自身運(yùn)行邏輯及系統(tǒng)的內(nèi)部時(shí)鐘變化來產(chǎn)生相應(yīng)的輸出。
所謂“明顯的邊界”是指系統(tǒng)所產(chǎn)生的輸出是明確而無二義性的。我們稱這個(gè)邊界為系統(tǒng)的設(shè)計(jì)規(guī)范（specification）。一個(gè)系統(tǒng)通過與其所處環(huán)境進(jìn)行交互，從而獲取輸入并產(chǎn)生輸出。一個(gè)系統(tǒng)可以被拆解為不同的子系統(tǒng)。這些子系統(tǒng)通常被稱為系統(tǒng)模塊（system components），每個(gè)模塊又獨(dú)立地成為一個(gè)系統(tǒng)，作為一個(gè)系統(tǒng)，這個(gè)模塊又會(huì)和它的相關(guān)環(huán)境進(jìn)行交互（比如，一個(gè)更大的系統(tǒng)中的其他的模塊組件）來獲取輸入并產(chǎn)生輸出，這些模塊還可以繼續(xù)被分解為更小的子系統(tǒng)。
一個(gè)系統(tǒng)可以被建模為一個(gè)狀態(tài)機(jī)（state machine），其中的狀態(tài)包含了系統(tǒng)所持有并處理的數(shù)據(jù)。這些狀態(tài)的遷移被分為兩大類：由系統(tǒng)內(nèi)部邏輯所觸發(fā)且對(duì)外部環(huán)境透明的遷移和直接與外部環(huán)境相接觸的遷移。前者的例子如內(nèi)存數(shù)據(jù)和寄存器數(shù)據(jù)的轉(zhuǎn)換，內(nèi)存中數(shù)據(jù)結(jié)構(gòu)的重組。第二種遷移的例子包含了各種各樣的系統(tǒng)和環(huán)境之間的交互，一般來說，如果這個(gè)過程能被建模成系統(tǒng)的I/O操作，則應(yīng)屬于這一類別。因此，一個(gè)消息內(nèi)容的形成是一個(gè)或多個(gè)第一類別狀態(tài)遷移的結(jié)果，但將消息輸出到系統(tǒng)的環(huán)境則是屬于第二類遷移。
第二類別的狀態(tài)遷移可以捕獲交互事件（interaction events），或者簡(jiǎn)單的事件（events）。這些事件可以由系統(tǒng)外部的觀察者（observer）來獲取。顯然，這里的事件是消息、信號(hào)、數(shù)據(jù)及其內(nèi)容以及一切系統(tǒng)和其環(huán)境交互（如機(jī)器人運(yùn)動(dòng)手腳，報(bào)警器報(bào)警，打印機(jī)打印等等）的發(fā)送和接受的模型。此外事件還可以用來描述系統(tǒng)缺乏交互的時(shí)間，比如一個(gè)計(jì)時(shí)器在日志中輸出系統(tǒng)的空閑時(shí)間等。
當(dāng)一個(gè)大的系統(tǒng)被拆分成多個(gè)模塊時(shí)，每個(gè)模塊都被賦予了整個(gè)系統(tǒng)所處理數(shù)據(jù)的一部分，正因?yàn)槟K和模塊間的接口銜接和數(shù)據(jù)感知，一些原來屬于第一類別的狀態(tài)轉(zhuǎn)換，因?yàn)橄到y(tǒng)的拆分在更低的層次上變成了第二類別，成為系統(tǒng)和環(huán)境之間的交互。
對(duì)于一個(gè)特定的系統(tǒng)，他對(duì)于輸入的形式和獲取時(shí)間是不可預(yù)知的，但是這個(gè)系統(tǒng)卻應(yīng)該能夠做到根據(jù)一個(gè)特定的輸入以及系統(tǒng)當(dāng)前的特定狀態(tài)獲取一個(gè)特定的輸出。因此系統(tǒng)的執(zhí)行可以被建模為狀態(tài)轉(zhuǎn)換序列，每個(gè)狀態(tài)的輸入是一個(gè)不確定性事件。為了記錄日志并做到故障恢復(fù)，我們還應(yīng)做到能夠在環(huán)境中捕獲這個(gè)不確定性事件輸入。
此外，在系統(tǒng)與系統(tǒng)間進(jìn)行交互式，事件的傳遞時(shí)間也應(yīng)該是不確定性的。
』
怎樣用日志來預(yù)防系統(tǒng)崩潰，在崩潰后如何還原系統(tǒng)，我想關(guān)鍵問題就是怎么做好內(nèi)存的快照，這樣，在斷電重啟后可以通過日志來還原內(nèi)存的信息這樣第一步就是確認(rèn)內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)，哪些是必不可少的。確定系統(tǒng)恢復(fù)的粒度，按照子系統(tǒng)的分割和事件的記錄來進(jìn)行replay，根據(jù)子系統(tǒng)的劃分，可以找出每個(gè)子系統(tǒng)中第二類別的事件進(jìn)行記錄。
以向數(shù)據(jù)庫(kù)系統(tǒng)提交作業(yè)為例，實(shí)際上在整個(gè)作業(yè)提交的過程中，每個(gè)層次都要做到可以在失敗的情況下重現(xiàn)，這個(gè)功能在完善的數(shù)據(jù)庫(kù)系統(tǒng)和集群批處理系統(tǒng)中當(dāng)然已經(jīng)很完善。但如果是針對(duì)web系統(tǒng)的作業(yè)提交，則需要針對(duì)Web的作業(yè)持久方案，做一個(gè)日志恢復(fù)處理。需要特別指出的是，對(duì)于數(shù)據(jù)的查詢是不需要做備份的。
在具體實(shí)現(xiàn)上，我想應(yīng)該包括：日志記錄，故障檢測(cè)，日志持久三個(gè)部分。一份日志就是一個(gè)對(duì)于系統(tǒng)檢查點(diǎn)（checkpoint）的連續(xù)記錄。日志記錄者負(fù)責(zé)記錄日志到日志持久者，故障檢測(cè)器隨時(shí)監(jiān)控系統(tǒng)，發(fā)現(xiàn)故障后，從日志持久者中讀取日志，進(jìn)行replay.
總算找到了工作.
我會(huì)好好努力的.
此時(shí)此刻,更加明白,以往的一切榮與辱都成為過去.
又要踏上新的征程.
剛看了myeclipse，eclipse是一個(gè)很可怕的東西，它試圖讓所有的開發(fā)人員一打開電腦就不能夠離開它，還要在里面完成所有的工作。人們不至于反感它的原因是它是開源的，不受商業(yè)控制的。如果我們對(duì)于myeclipse過度依賴，必然最終走向?qū)ξ④泧?yán)重依賴的老路。我不反對(duì)利用軟件盈利。但是自由的精神不應(yīng)被改變。
微軟和我們
是原始的獵人與獵物之間的關(guān)系，虎與倀的關(guān)系，最終極的占有。我們這才生是MS的人，死是MS的鬼。
摘要: 這篇隨筆談一談如何在Java環(huán)境下利用Unix/Linux的用戶名和密碼對(duì)用戶的權(quán)限作出過濾。為方便大家學(xué)習(xí)交流，本文中給出了源代碼，借此拋磚引玉，歡迎大家對(duì)這個(gè)簡(jiǎn)單的登錄模型做出改進(jìn)或者設(shè)計(jì)出自己的技術(shù)方案。
由標(biāo)題我們不難看出，與本文相關(guān)的知識(shí)點(diǎn)主要有3個(gè)：
1 JAAS這個(gè)解耦設(shè)計(jì)的多層驗(yàn)證方法（1.4后已歸入Java核心庫(kù)中）
2 應(yīng)用JNI訪問底層代碼，及JNI中簡(jiǎn)單的類型匹配
3 在shadow模式下，Unix/Linux系統(tǒng)的用戶驗(yàn)證
閱讀全文