@beneo
一般ThreadLocal導(dǎo)致內(nèi)存泄漏都有人以非靜態(tài)的方式不斷創(chuàng)建ThreadLocal，所以悲劇了。

@beneo
你的建議是對(duì)的，隨后會(huì)補(bǔ)上。積累到一段時(shí)間之后再發(fā)布新版的版本。

@3220
使用%F解決了輸出格式問(wèn)題，但是LOG Leval的配置還是按照類(lèi)別來(lái)區(qū)分，問(wèn)題還是依然存在的。

@隔葉黃鶯
log4j.properties文件中，layout.ConversionPattern一般都是%c或者%c{1}來(lái)顯示類(lèi)名，你還能怎么配？

@隔葉黃鶯
例如：
Class Service {
protected final LogFactory.getLog(this.getClass());
}

Class ServiceA extends Service {
public void foo("foo");
}

Class ServiceB extends ServiceA{
public void bar("bar");
}

這種情況，如果ServiceB的實(shí)例調(diào)用了foo的日志，LOG輸出的類(lèi)是ServiceB，而不是ServiceA，但是我們需要分析問(wèn)題時(shí)，需要的是ServiceA，配置文件也是應(yīng)該配在ServiceA上的。

@張雅靜
你去訪(fǎng)問(wèn)www.youshang.com注冊(cè)，填寫(xiě)手機(jī)號(hào)碼，會(huì)有客服回訪(fǎng)，可以詳細(xì)了解一切。
關(guān)于安全，有類(lèi)似于網(wǎng)上銀行移動(dòng)證書(shū)的“友盾”，安全還有有保證的。

@3220
性能這兩種方式是非常接近的，而且static聲明的方式性能會(huì)更好，實(shí)例化的方式更方便，struts、spring都采用了更方便的做法，但是更方便的做法，就會(huì)在類(lèi)被繼承的時(shí)候?qū)е翷OG輸出混亂。像struts、spring框架的類(lèi)通常不會(huì)被繼承，但總是存在一些情況需要繼承的，一旦出現(xiàn)繼承框架的類(lèi)，例如你編寫(xiě)一個(gè)類(lèi)繼承自ClassPathXmlApplicationContext，那么LOG輸出就會(huì)產(chǎn)生混亂的。

綜合比較：
方式A 基類(lèi)實(shí)例化Log LOG = LogFactory.getLog(this.getClass())
方式B 每個(gè)類(lèi)單獨(dú)聲明 static Log LOG = LogFactory.getLog(XXX.class)
性能 兩種方式接近
方便 方式A更方便，不需要再子類(lèi)中再聲明。
不良后果 在類(lèi)被繼承時(shí)，使用方式A會(huì)導(dǎo)致日志輸出混亂

@隔葉黃鶯
你的說(shuō)法不對(duì)，例如LOG4J能夠把記錄日志的類(lèi)和代碼行數(shù)輸出，如果使用
protected final Log LOG = LogFactory.getLog(this.getClass())的方式，就會(huì)導(dǎo)致不能夠簡(jiǎn)單的方式定位問(wèn)題了。

使用全大寫(xiě)的方式挺好的，最初在JXTA中看到這種用法，反復(fù)比較之后，覺(jué)得使用大寫(xiě)LOG比小寫(xiě)logger更清晰。

@seewood
不是因?yàn)樾阅艿膯?wèn)題，是因?yàn)槔^承時(shí)會(huì)導(dǎo)致LOG錯(cuò)亂，例如你繼承了Spring的ClassPathXmlApplicationContext時(shí)，日志輸出的的類(lèi)名不對(duì)了。

回kingslee
1、State有三個(gè)field，parent、index和files，不聲明一個(gè)對(duì)象，使用ArrayList不好，聲明一個(gè)對(duì)象語(yǔ)義更明確。
2、這是深度優(yōu)先的，廣度優(yōu)先的實(shí)現(xiàn)方式會(huì)有所不同。

@久城
如果你使用json-lib，可以讓對(duì)象實(shí)現(xiàn)JSONString接口，另外json-lib有一些配置參數(shù)，但是json-lib做的不好。

@Strive
既然你做的RPC，就應(yīng)該使用方法的簽名自動(dòng)轉(zhuǎn)換JSON數(shù)據(jù)到目標(biāo)類(lèi)型。[]格式的JSONArray轉(zhuǎn)到目標(biāo)的ArrayList是很容易的事情啊

@simon.xu
你說(shuō)的方法在過(guò)去的系統(tǒng)中用過(guò)，每次遞增一批，這算是方案2的改進(jìn)。使用方案3，在種子上作一些處理之后，能夠更好實(shí)現(xiàn)全局唯一，可以確保不同服務(wù)器不同的數(shù)據(jù)庫(kù)分配出來(lái)的ID唯一。

從我博客主站上看：
http://www.cnblogs.com/jobs/archive/2007/11/16/961116.html

評(píng)論更多，描述了更詳盡的情況。

下載看了一下，似乎做的內(nèi)容還是相當(dāng)少。

建議你參考一下金蝶軟件EAS BOS的KSQL，是一個(gè)應(yīng)用在產(chǎn)品中的成熟的SQL翻譯。單是測(cè)試用例就有數(shù)千個(gè)，支持Oracle、Microsoft SQL Server、Sybase、DB2、DB2 AS400。手工編寫(xiě)的文法分析，沒(méi)有使用antlr，速度大約是antlr生成Parser的三至四倍左右吧。

KSQL的功能也比較完備，支持臨時(shí)表、游標(biāo)、流程控制語(yǔ)句WHILE、IF等。

這樣的底層核心模塊關(guān)鍵是穩(wěn)定、高效、功能完備。高效還容易，穩(wěn)定是最難的，需要大量的測(cè)試，包括實(shí)際應(yīng)用中的測(cè)試，DB2的限制是最多的，你沒(méi)有實(shí)際測(cè)試，可能想不到DB2的限制有如此之多。

我覺(jué)得你現(xiàn)在這三點(diǎn)都不具備。

@Robin's Java World
@太陽(yáng)里的雪
你們都沒(méi)認(rèn)真想想，SEED只需要獲取一次，然后就一直使用。而SEED的獲取只需要在程序啟動(dòng)時(shí)！

@liigo，我改了一下示例代碼，不過(guò)意思還一樣的。
回答你的問(wèn)題，通常都是執(zhí)行一次就會(huì)退出循環(huán)了

@劉甘泉
maven的入門(mén)教程目前還是做得不夠，入門(mén)需要花費(fèi)一點(diǎn)時(shí)間，但是只需要一個(gè)人在項(xiàng)目中導(dǎo)入之后，以后都好辦了。

@xyz20003
缺省的central repository是很慢的。有一個(gè)鏡像超級(jí)快，你可以試試看：
http://mirrors.redv.com/maven2/
在pom.xml中加入：

<repositories>
<repository>
<id>central</id>
<name>Internal Repository</name>
<url>http://mirrors.redv.com/maven2</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Internal Repository</name>
<url>http://mirrors.redv.com/maven2</url>
</pluginRepository>
</pluginRepositories>

增加了一些內(nèi)容。其中圖示還欠缺，由于圖示工作量很大，一時(shí)難以補(bǔ)全，慢慢來(lái)吧。
目前版本2007-5-9，更新日期和版本日期相同，已下載的朋友，請(qǐng)重新下載。

原來(lái)文章中有DelayItem的，昨天加入一些內(nèi)容時(shí)，不小心把DelayItem部分的代碼刪除了。現(xiàn)已經(jīng)補(bǔ)上，請(qǐng)看正文。

在Linux下使用Firefox、Eclipse等軟件，當(dāng)某個(gè)操作阻塞的時(shí)候，整個(gè)程序甚至整個(gè)Gnome桌面會(huì)停止響應(yīng)。

這一現(xiàn)象和用戶(hù)線(xiàn)程出現(xiàn)阻塞的現(xiàn)象吻合。

使用Ubuntu工作一段時(shí)間了，說(shuō)實(shí)在，沒(méi)有在Windows XP下流暢。

同一臺(tái)機(jī)器上，Eclipse跑在Windows XP下的性能比Ubuntu LInux下快多了，在Linux下，經(jīng)常出現(xiàn)某個(gè)操作阻塞時(shí)，整個(gè)Eclipse失去響應(yīng)，而在Windows下，很少出現(xiàn)這種情況。

其實(shí)偶不是很清楚Linux下pthread的最終實(shí)現(xiàn)，看過(guò)資料，說(shuō)pthread是用戶(hù)線(xiàn)程庫(kù)。

在solaris下，pthread的用戶(hù)線(xiàn)程和內(nèi)核線(xiàn)程影射，是多對(duì)多的。

Windows下Fiber也可以實(shí)現(xiàn)多對(duì)多。

linux下的實(shí)現(xiàn)，我了解還不多，2.6在線(xiàn)程支持方面有重大變化，但偶還沒(méi)花時(shí)間去學(xué)習(xí)。

Scott Meyers是大師啊，笑死人了。

似乎只有他自己認(rèn)為是C++領(lǐng)域權(quán)威吧，而他實(shí)際只是一個(gè)技術(shù)講師而已。

@weidagang2046
你自己去看《Unix網(wǎng)絡(luò)編程》第三版第一卷

這份名單，得高分的公司，可能有作弊的嫌疑 ：）

初學(xué)者，很容易被一些瑕疵蒙蔽了自己的眼睛，而沒(méi)看到Java語(yǔ)言的優(yōu)勢(shì)。