indexed fields

    indexed fields 的数量将会影响以下的一些性能：

•         索引时的时候的内存使用量
•         索引段的合并时间
•         优化时间
•         索引的大小

     我们可以通过 将 omitNorms=“true” 来减少indexed fields数量增加所带来的影响。

   stored fields

      Retrieving the stored fields  确实是一种开销。这个开销，受每个文档所存储的字节影响很大。每个文档的所占用的空间越大，文档就显的更稀疏，这样从硬盘中读取数据，就需要更多的i/o操作（通常，我们在存储比较大的域的时候，就会考虑这样的事情，比如存储一篇文章的文档。）

       可以考虑将比较大的域放到solr外面来存储。如果你觉得这样做会有些别扭的话，可以考虑使用压缩的域，但是这样会加重cpu在存储和读取域的时候的负担。不过这样却是可以较少i/0的负担。

       如果，你并不是总是使用 stored fields 的话，可以使用stored field的延迟加载，这样可以节省很多的性能，尤其是使用compressed field 的时候。

 Configuration Considerations

      mergeFactor

         这个是合并因子，这个参数大概决定了segment(索引段)的数量。

         合并因子这个值告诉lucene，在什么时候，要将几个segment合并成为一个segment, 合并因子就像是一个数字系统的基数一样。

         比如说，如果你将合并因子设成10，那么每往索引中添加1000个文档的时候，就会创建一个新的索引段。当第10个大小为1000的索引段添加进来的时候，这十个索引段就会被合并成一个大小为10，000的索引段。当十个大小为10，000的索引段生成的时候，它们就会被合并成一个大小为100，000 的索引段。如此类推下去。

         这个值可以在 solrconfig.xml 中的 *mainIndex*中设置。（不用管indexDefaults中设置）

       mergeFactor Tradeoffs

         较高的合并因子

•         会提高索引速度
•         较低频率的合并，会导致 更多的索引文件，这会降低索引的搜索效率

          较低的合并因子

•         较少数量的索引文件，能加快索引的搜索速度。
•         较高频率的合并，会降低索引的速度。

Cache autoWarm Count Considerations

      当一个新的 searcher 打开的时候，它缓存可以被预热，或者说使用从旧的searcher的缓存的数据来“自动加热”。autowarmCount是这样的一个参数，它表示从旧缓存中拷贝到新缓存中的对象数量。autowarmCount这个参数将会影响“自动预热”的时间。有些时候，我们需要一些折中的考虑，seacher启动的时间和缓存加热的程度。当然啦，缓存加热的程度越好，使用的时间就会越长，但往往，我们并不希望过长的seacher启动时间。这个autowarm 参数可以在solrconfig.xml文件中被设置。

       详细的配置可以参考solr的wiki。

Cache hit rate（缓存命中率）

       我们可以通过solr的admin界面来查看缓存的状态信息。提高solr缓存的大小往往是提高性能的捷径。当你使用面搜索的时候，你或许可以注意一下filterCache,这个是由solr实现的缓存。

Explicit Warming of Sort Fields 

       如果你有许多域是基于排序的，那么你可以在"newSearcher"和"firstSearcher"event listeners中添加一些明显需要预热的查询，这样FieldCache 就会缓存这部分内容。

 Optimization Considerations

        优化索引，是我们经常会做的事情，比如，当我们建立好索引，然后这个索引不会再变更的情况，我们就会做一次优化了。

        但，如果你的索引经常会改变，那么你就需要好好的考虑下面的因素的。

•        当越来越多的索引段被加进索引，查询的性能就会降低， lucene对索引段的数量有一个上限的限制，当超过这个限制的时候，索引段可以自动合并成为一个。
• 在同样没有缓存的情况下，一个没有经过优化的索引的性能会比经过优化的索引的性能少10%……
• 自动加热的时间将会变长，因为它依赖于搜索。
•  优化将会对索引的分发产生影响。
•  在优化期间，文件的大小将会是索引的两倍，不过最终将会回到它原来的大小，或者会更小一点。

      优化，会将所有的索引段合并成为一个索引段，所以，优化这个操作其实可以帮助避免“too many files”这个问题，这个错误是由文件系统抛出的。

Updates and Commit Frequency Tradeoffs

         如果从机太经常从主机更新的话，从机的性能是会受到影响的。为了避免，由于这个问题而引起的性能下降，我们还必须了解从机是怎样执行更新的，这样我们才能更准确去调节一些相关的参数（commit的频率，spappullers,autowarming/autocount）,这样，从机的更新才不会太频繁。

1.      执行commit操作会让solr新生成一个snapshot。如果将postCommit参数设成true的话，optimization也会执行snapShot.
2.      slave上的Snappuller程序一般是在crontab上面执行的，它会去master询问，有没有新版的snapshot。一旦发现新的版本，slave就会把它下载下来，然后snapinstall.
3.      每次当一个新的searcher被open的时候，会有一个缓存预热的过程，预热之后，新的索引才会交付使用。

      这里讨论三个有关的参数：

•      number/frequency of snapshots   ----snapshot的频率。
•      snappullers 是   在crontab中的，它当然可以每秒一次、每天一次、或者其他的时间间隔一次运行。它运行的时候，只会下载slave上没有的，并且最新的版本。
•      Cache autowarming 可以在solrconfig.xml文件中配置。

           如果，你想要的效果是频繁的更新slave上的索引，以便这样看起来比较像“实时索引”。那么，你就需要让snapshot尽可能频繁的运行，然后也让 snappuller频繁的运行。这样，我们或许可以每5分钟更新一次，并且还能取得不错的性能，当然啦，cach的命中率是很重要的，恩，缓存的加热时间也将会影响到更新的频繁度。

       cache对性能是很重要的。一方面，新的缓存必须拥有足够的缓存量，这样接下来的的查询才能够从缓存中受益。另一方面，缓存的预热将可能占用很长一段时间，尤其是，它其实是只使用一个线程，和一个cpu在工作。snapinstaller太频繁的话，solr slave将会处于一个不太理想的状态，可能它还在预热一个新的缓存，然而一个更新的searcher被opern了。

         怎么解决这样的一个问题呢，我们可能会取消第一个seacher，然后去处理一个更新seacher，也即是第二个。然而有可能第二个seacher 还没有被使用上的时候，第三个又过来了。看吧，一个恶性的循环，不是。当然也有可能，我们刚刚预热好的时候就开始新一轮的缓存预热，其实，这样缓存的作用压根就没有能体现出来。出现这种情况的时候，降低snapshot的频率才是硬道理。

    Query Response Compression

        在有些情况下，我们可以考虑将solr xml response 压缩后才输出。如果response非常大，就会触及NIc i/o限制。

        当然压缩这个操作将会增加cpu的负担，其实，solr一个典型的依赖于cpu处理速度的服务，增加这个压缩的操作，将无疑会降低查询性能。但是，压缩后的数据将会是压缩前的数据的6分之一的大小。然而solr的查询性能也会有15%左右的消耗。

       至于怎样配置这个功能，要看你使用的什么服务器而定，可以查阅相关的文档。

     Embedded vs HTTP Post

         使用embeded 来建立索引，将会比使用xml格式来建立索引快50%。

     RAM Usage Considerations（内存方面的考虑）

        OutOfMemoryErrors

           如果你的solr实例没有被指定足够多的内存的话，java virtual machine也许会抛outof memoryError，这个并不对索引数据产生影响。但是这个时候，任何的 adds/deletes/commits操作都是不能够成功的。

         Memory allocated to the Java VM

            最简单的解决这个方法就是，当然前提是java virtual machine 还没有使用掉你全部的内存，增加运行solr的java虚拟机的内存。

           Factors affecting memory usage（影响内存使用量的因素）

             我想，你或许也会考虑怎样去减少solr的内存使用量。

              其中的一个因素就是input document的大小。

              当我们使用xml执行add操作的时候，就会有两个限制。

•      document中的field都是会被存进内存的，field有个属性叫maxFieldLength，它或许能帮上忙。
•      每增加一个域，也是会增加内存的使用的。

（当切换SolrIndexSearcher时可能会有两个同时提供服务），而Solr的各种Cache是依附于SolrIndexSearcher的，SolrIndexSearcher在则Cache 生，SolrIndexSearcher亡则Cache被清空close掉。

Solr中的应用Cache有filterCache、 queryResultCache、documentCache等，这些Cache都是SolrCache的实现类，

并且是 SolrIndexSearcher的成员变量，各自有着不同的逻辑和使命，下面分别予以介绍和分析。

1、SolrCache接口实现类

Solr提供了两种SolrCache接口实现类：solr.search.LRUCache和solr.search.FastLRUCache。

FastLRUCache是1.4版本中引入的，其速度在普遍意义上要比LRUCache更fast些。
下面是对SolrCache接口主要方法的注释：

that match a query.When a new searcher is opened, its caches may be prepopulatedor "autowarmed"

 using data from caches in the old searcher.autowarmCount is the number of items to prepopulate. 

 For LRUCache,the prepopulated items will be the most recently accessed items.-->

<filterCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>

<queryResultCacheclass="solr.LRUCache"size="16384"initialSize="4096"/>

publicQueryResultKey(Query query, List<Query>filters, Sort sort,intnc_flags)

 {

     this.query=query;

     this.sort=sort;

     this.filters=filters;

     this.nc_flags=nc_flags;

     inth=query.hashCode();

     if(filters!=null)h^=filters.hashCode();

     sfields=(this.sort!=null)?this.sort.getSort():defaultSort;

    for(SortField sf:sfields)

    { // mix the bits so that sortFields are position dependent

 // so that a,b won't hash to the same value as b,ah^=(h<<8)|(h>>>25);

 // reversible hashif(sf.getField()!=null)h+=sf.getField().hashCode();h+=sf.getType();

 if(sf.getReverse())h=~h;if(sf.getLocale()!=null)h+=sf.getLocale().hashCode();

 if(sf.getFactory()!=null)h+=sf.getFactory().hashCode();}hc=h;

 }

of document idsare collected.  For example, of a search for a particular queryrequests matching documents 10 

through 19, and queryWindowSize is 50,then documents 0 through 50 will be collected and cached.  

Any furtherrequests in that range can be satisfied via the cache.-->

<queryResultWindowSize>50</queryResultWindowSize>

相比filterCache来说，queryResultCache内存使用上要更少一些，但它的效果如何就很难说。

就索引数据来说，通常我们只是在索引上存储应用主键id，再从数据库等数据源获取其他需要的字段。

这使得查询过程变成，首先通过solr得到document id set，再由Solr得到应用id集合，

最后从外部数据源得到完成的查询结果。如果对查询结果正确性没有苛刻的要求，可以在Solr之外独立的缓存完整的



查询结果（定时作废），这时queryResultCache就不是很有必要，否则可以考虑使用queryResultCache。当然，如果发现在

queryResultCache生命周期内，query重合度很低，也不是很有必要开着它。 

又顾名思义，documentCache用来保存<doc_id,document>对的。如果使用documentCache，就尽可能开大



些，至少要大过<max_results> *<max_concurrent_queries>，否则因为cache的淘汰，

一次请求期间还需要重新获取document一次。也要注意document中存储的字段的多少，避免大量的内存消耗。

下面是documentCache的配置示例：<!-- documentCache caches Lucene Document objects (the stored fields for each document).-->

<documentCacheclass="solr.LRUCache"size="16384"initialSize="16384"/>

5、User/Generic Caches 

Solr支持自定义Cache，只需要实现自定义的regenerator即可，下面是配置示例：<!-- Example of a generic cache.  These caches may be accessed by namethrough SolrIndexSearcher.getCache(),

cacheLookup(), and cacheInsert().The purpose is to enable easy caching of user/application level data.

The regenerator argument should be specified as an implementationof solr.search.CacheRegenerator if

 autowarming is desired.--><!--<cache name="yourCacheNameHere"class="solr.LRUCache"size="4096"

initialSize="2048"regenerator="org.foo.bar.YourRegenerator"/>-->

6、The Lucene FieldCache 

lucene中有相对低级别的FieldCache，Solr并不对它做管理，所以，lucene的FieldCache还是由lucene的IndexSearcher来搞。 

上面有提到autowarm，autowarm触发的时机有两个，一个是创建第一个Searcher时（firstSearcher），一个是创建个新



Searcher（newSearcher）来代替当前的Searcher。在Searcher提供请求服务前，Searcher中的各个Cache可以

做warm处理，处理的地方通常是SolrCache的init方法，而不同cache的warm策略也不一样。

1）filterCache：filterCache注册了下面的CacheRegenerator，就是由旧的key查询索引得到新值put到新cache中。solrConfig.filterCacheConfig.setRegenerator(newCacheRegenerator(){publicbooleanregenerateItem

(SolrIndexSearcher newSearcher, SolrCache newCache, SolrCache oldCache,ObjectoldKey,ObjectoldVal)

throwsIOException{newSearcher.cacheDocSet((Query)oldKey,null,false);returntrue;}});

 2）queryResultCache：queryResultCache的autowarm不在SolrCache的init（也就是说，不是去遍历已

 有的queryResultCache中的query key执行查询），而是通过SolrEventListener接口的void

newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher

currentSearcher)方法，来执行配置中特定的query查询，达到显示的预热lucene FieldCache的效果。

queryResultCache的配置示例如下：

<listenerevent="newSearcher"class="solr.QuerySenderListener"><arrname="queries"><!-- seed common sort fields --><lst>

<strname="q">anything</str><strname="sort">name desc price desc populartiy desc</str></lst></arr>

</listener><listenerevent="firstSearcher"class="solr.QuerySenderListener"><arrname="queries">

<!-- seed common sort fields --><lst><strname="q">anything</str><strname="sort">

name desc, price desc, populartiy desc</str></lst><!-- seed common facets and filter queries -->

<lst><strname="q">anything</str><strname="facet.field">category</str>

<strname="fq">inStock:true</str><strname="fq">price:[0 TO 100]</str></lst></arr></listener>

3）documentCache：因为新索引的document id和索引文档的对应关系发生变化，所以documentCache没有warm的过程，

落得白茫茫一片真干净。尽管autowarm很好，也要注意autowarm带来的开销，这需要在实际中检验其warm的开销，

也要注意Searcher的切换频率，避免因为warm和切换影响Searcher提供正常的查询服务。



8、参考文章 

http://wiki.apache.org/solr/SolrCaching

• 中心化集群配置
• 自动容灾
• 近实时搜索
• 领导选举
• 索引持久化

http://zhoujianghai.iteye.com/blog/1540176

首先介绍一下solr：

Apache Solr (读音: SOLer) 是一个开源、高性能、采用Java开发、基于Lucene的全文搜索服务器，文档通过Http利用XML加到一个搜索集合中，查询该集合也是通过 http收到一个XML/JSON响应来实现。Solr 中存储的资源是以 Document 为对象进行存储的。每个文档由一系列的 Field 构成，每个 Field 表示资源的一个属性。Solr 中的每个 Document 需要有能唯一标识其自身的属性，默认情况下这个属性的名字是 id，在 Schema 配置文件（schema.xml）中使用：<uniqueKey>id</uniqueKey>进行描述。solr有两个核心文件，solrconfig.xml和schema.xml。solrconfig.xml是solr的基础文件，里面配置了各种web请求处理器、请求响应处理器、日志、缓存等;schema.xml配置映射了各种数据类型的索引方案，分词器的配置、索引文档中包含的字段也在此配置。

工作中主要用来分词和搜索，简单的工作原理是：利用分词器对数据源进行分词处理，然后根据分词结果建立索引库;查询的时候，利用分词器对查询语句进行分词，根据查询语句分词的结果在索引库中进行匹配，最后返回结果。

废话少说，下面开始solr之旅吧：

一.安装JDK和Tomcat

（2）：安装tomcat，下载tomcat安装包，解压到apache-tomcat目录下

修改tomcat安装目录下的conf目录的server.xml

找到<Connector port="8080" .../>，加入URIEncoding="UTF-8"，为了支持中文。

设置Java和tomcat环境变量

上面两步比较简单，这里就只简单描述一下，不明白的可以网上查资料。

二. 安装solr

下载solr包，http://labs.renren.com/apache-mirror/lucene/solr/3.5.0/apache-solr-3.5.0.zip

解压缩到apache-solr目录，把apache-solr/dist目录下的apache-solr-3.5.0.war 复制到$TOMCAT_HOME/webapps目录下，重命名为solr.war

复制apache-solr/example/solr到tomcat根目录下（如果你想配置多core（实例），就复制apache-solr /example/multicore到tomcat根目录下，不用复制solr了），作为solr/home，以后也可以往该目录添加 core，每个core下面都可以有自己的配置文件。

在apache-tomcat/conf/Catalina/localhost/下创建solr.xml（跟webapps下的solr项目同名），指定solr.war和solr/home的位置，让tomcat启动时就自动加载该应用。

solr.xml内容如下：

<?xml version="1.0" encoding="UTF-8"?>

<Context docBase="/home/zhoujh/java/apache-tomcat7/webapps/solr.war" debug="0" crossContext="true" >

   <Environment name="solr/home" type="java.lang.String" value="/home/zhoujh/java/apache-tomcat7/solr" override="true" />

</Context>

然后在tomcat的bin目录下执行./startup.sh，启动tomcat

在地址栏访问http://localhost:8080/solr/

将会出现solr欢迎界面和admin入口

注：如果出现org.apache.solr.common.SolrException: Error loading class 'solr.VelocityResponseWriter' 异常，最简单的解决方法：找到$TOMCAT_HOME/solr/conf/solrconfig.xml，把<queryResponseWriter name="velocity" class="solr.VelocityResponseWriter" enable="${solr.velocity.enabled:true}"/>注释掉或者enable:false即可。如果一切顺利的话，现在可以看到solr的web管理界面了。不过要想实现分词的功能，得安装一个中文分词器，这里推荐IKAnalyzer或mmseg4j。

IKAnalyzer是一个开源的，基于java语言开发的轻量级的中文分词工具包，采用了特有的“正向迭代最细粒度切分算法“，具有60万字/秒的高速处理能力，采用了多子处理器分析模式，支持：英文字母（IP地址、Email、URL）、数字（日期，常用中文数量词，罗马数字，科学计数法），中文词汇（姓名、地名处理）等分词处理。优化的词典存储，更小的内存占用。支持用户词典扩展定。

mmseg4j 用 Chih-Hao Tsai 的 MMSeg 算法(http://technology.chtsai.org/mmseg/ )实现的中文分词器，并实现 lucene 的 analyzer 和 solr 的TokenizerFactory 以方便在Lucene和Solr中使用。MMSeg 算法有两种分词方法：Simple和Complex，都是基于正向最大匹配。Complex 加了四个规则过虑。官方说：词语的正确识别率达到了 98.41%。mmseg4j 已经实现了这两种分词算法。

三. 配置中文分词器

下面分别安装这两个中文分词器，当然选择安装其中一个也是可以的。

（1）安装IKAnalyzer

下载地址： http://code.google.com/p/ik-analyzer/downloads/list

在当前目录下新建IKAnalyzer目录，解压到该目录下：unzip IKAnalyzer2012_u5.zip -d ./IKAnalyzer

把IKAnalyzer目录下的IKAnalyzer2012.jar文件拷贝到 $TOMCAT_HOME/webapps/solr/WEB-INF/lib/下

配置schema.xml，编辑$TOMCAT_HOME/solr/conf/schema.xml，在文件中添加下面这个fieldtype

注：下面的代码中多了很多“<span style="font-size: x-small;">”标签，这个是设置字体时iteye编辑器自己生成的。

<span style="font-size: x-small;"><span style="font-size: x-small;"><span style="font-size: small;"><fieldType name="text" class="solr.TextField" positionIncrementGap="100">
        <analyzer type="index">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="false" /> 
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />  
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="1" />                
            <filter class="solr.LowerCaseFilterFactory" />  
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />      
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />  
        </analyzer>
        <analyzer type="query">
            <tokenizer class = "org.wltea.analyzer.solr.IKTokenizerFactory" isMaxWordLength="true" />  
            <filter class="solr.SynonymFilterFactory" synonyms="synonyms.txt" ignoreCase="true" expand="true" />  
            <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" />  
            <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="1" />  
            <filter class="solr.LowerCaseFilterFactory" />  
            <filter class="solr.EnglishPorterFilterFactory" protected="protwords.txt" />  
            <filter class="solr.RemoveDuplicatesTokenFilterFactory" />  
        </analyzer>
    </fieldType></span></span></span>

<field name="game_name" type="text" indexed="true" stored="true" required="true" />

然后找到这一句：<defaultSearchField>text</defaultSearchField>把它改成<defaultSearchField>game_name</defaultSearchField>

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp，就可以进行分词处理了。

IKAnalyzer添加自定义分词词典：词典文件格式为无BOM的UTF-8编码的文本文件,文件扩展名不限，一次可以添加多个词库，每个词库以";"分开。把IKAnalyzer 目录下的IKAnalyzer.cfg.xml和stopword.dic拷贝到$TOMCAT_HOME/webapps/solr/WEB_INF /classes目录下，可以自己新建一个mydic.dic文件，然后在IKAnalyzer.cfg.xml里进行配置。

（2）安装mmseg4j

 下载地址：http://code.google.com/p/mmseg4j/downloads/list

在当前目录下新建mmseg4j目录，解压到该目录下：unzip mmseg4j-1.8.5.zip -d ./mmseg4j

把mmseg4j目录下的mmseg4j-all-1.8.5.jar文件拷贝到 $TOMCAT_HOME/webapps/solr/WEB-INF/lib/下

配置schema.xml，编辑$TOMCAT_HOME/solr/conf/schema.xml，在文件中添加下面这个fieldtype

<fieldtype name="textComplex" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="complex" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>
    <fieldtype name="textMaxWord" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="max-word" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>
    <fieldtype name="textSimple" class="solr.TextField" positionIncrementGap="100">
        <analyzer>
            <tokenizer class="com.chenlb.mmseg4j.solr.MMSegTokenizerFactory" mode="simple" dicPath="/home/zhoujh/java/apache-tomcat7/solr/dict">
            </tokenizer>
        </analyzer>
    </fieldtype>

注意：dicPath的值改成你自己机器上相应的目录。

然后修改之前添加的filed，让其使用mmseg4j分词器

<field name="game_name" type="textComplex" indexed="true" stored="true" required="true" />

配置mmseg4j分词词典：MMSEG4J的词库是可以动态加载的，词库的编码必须是UTF-8，mmseg4j 默认从当前目录下的 data 目录读取上面的文件，当然也可以指定别的目录，比如我就放在自定义的dict目录下。自定义词库文件名必需是 "words" 为前缀和 ".dic" 为后缀。如：/data/words-my.dic。

这里直接把mmseg4j/data目录下的所有.dic文件拷贝到$TOMCAT_HOME/solr/dict目录下。共有：4个dic文件，chars.dic、units.dic、 words.dic、 words-my.dic。下面简单解释一下这几个文件的作用。

1、chars.dic，是单个字，和对应的频率，一行一对，字在全面，频率在后面，中间用空格分开。这个文件的信息是 complex 模式要用到的。在最后一条过虑规则中使用了频率信息。

2、units.dic，是单位的字，如：分、秒、年。

3、words.dic，是核心的词库文件，一行一条，不需要其它任何数据（如词长）。

4、words-my.dic，是自定义词库文件

在浏览器打开http://localhost:8080/solr/admin/analysis.jsp，就可以看到分词效果了。

现在，这两种分词方法都已配置好了，想用哪种就把查询的filed的type设置成哪种。

一、字段配置（schema）

schema.xml位于solr/conf/目录下，类似于数据表配置文件，

定义了加入索引的数据的数据类型，主要包括type、fields和其他的一些缺省设置。

1、先来看下type节点，这里面定义FieldType子节点，包括name,class,positionIncrementGap等一些参数。

• name：就是这个FieldType的名称。
• class：指向org.apache.solr.analysis包里面对应的class名称，用来定义这个类型的行为。

必要的时候fieldType还需要自己定义这个类型的数据在建立索引和进行查询的时候要使用的分析器analyzer，包括分词和过滤，如下：

2、再来看下fields节点内定义具体的字段（类似数据库的字段），含有以下属性：

• name：字段名
• type：之前定义过的各种FieldType
• indexed：是否被索引
• stored：是否被存储（如果不需要存储相应字段值，尽量设为false）
• multiValued：是否有多个值（对可能存在多值的字段尽量设置为true，避免建索引时抛出错误）

3、建议建立一个拷贝字段，将所有的 全文本 字段复制到一个字段中，以便进行统一的检索：

     以下是拷贝设置：

4、动态字段，没有具体名称的字段，用dynamicField字段

如：name为*_i，定义它的type为int，那么在使用这个字段的时候，任务以_i结果的字段都被认为符合这个定义。如name_i, school_i

schema.xml文档注释中的信息：

1、为了改进性能，可以采取以下几种措施：

• 将所有只用于搜索的，而不需要作为结果的field（特别是一些比较大的field）的stored设置为false
• 将不需要被用于搜索的，而只是作为结果返回的field的indexed设置为false
• 删除所有不必要的copyField声明
• 为了索引字段的最小化和搜索的效率，将所有的 text fields的index都设置成field，然后使用copyField将他们都复制到一个总的 text field上，然后对他进行搜索。
• 为了最大化搜索效率，使用java编写的客户端与solr交互（使用流通信）
• 在服务器端运行JVM（省去网络通信），使用尽可能高的Log输出等级，减少日志量。

2、< schema name =" example " version =" 1.2 " >

• name：标识这个schema的名字
• version：现在版本是1.2

3、filedType

< fieldType name =" string " class =" solr.StrField " sortMissingLast =" true " omitNorms =" true " />

• name：标识而已。
• class和其他属性决定了这个fieldType的实际行为。（class以solr开始的，都是在org.appache.solr.analysis包下）

可选的属性：

• sortMissingLast和sortMissingFirst两个属性是用在可以内在使用String排序的类型上（包括：string,boolean,sint,slong,sfloat,sdouble,pdate）。
• sortMissingLast="true"，没有该field的数据排在有该field的数据之后，而不管请求时的排序规则。
• sortMissingFirst="true"，跟上面倒过来呗。
• 2个值默认是设置成false

StrField类型不被分析，而是被逐字地索引/存储。

StrField和TextField都有一个可选的属性“compressThreshold”，保证压缩到不小于一个大小（单位：char）

< fieldType name =" text " class =" solr.TextField " positionIncrementGap =" 100 " >

solr.TextField 允许用户通过分析器来定制索引和查询，分析器包括一个分词器（tokenizer）和多个过滤器（filter）

• positionIncrementGap：可选属性，定义在同一个文档中此类型数据的空白间隔，避免短语匹配错误。

name:    字段类型名 
class:    java类名 
indexed:    缺省true。 说明这个数据应被搜索和排序，如果数据没有indexed，则stored应是true。 
stored:    缺省true。说明这个字段被包含在搜索结果中是合适的。如果数据没有stored,则indexed应是true。 
sortMissingLast:    指没有该指定字段数据的document排在有该指定字段数据的document的后面 
sortMissingFirst:    指没有该指定字段数据的document排在有该指定字段数据的document的前面 
omitNorms:    字段的长度不影响得分和在索引时不做boost时，设置它为true。一般文本字段不设置为true。 
termVectors:    如果字段被用来做more like this 和highlight的特性时应设置为true。 
compressed:    字段是压缩的。这可能导致索引和搜索变慢，但会减少存储空间，只有StrField和TextField是可以压缩，这通常适合字段的长度超过200个字符。 
multiValued:    字段多于一个值的时候，可设置为true。 
positionIncrementGap:    和multiValued
一起使用，设置多个值之间的虚拟空白的数量

< tokenizer class =" solr.WhitespaceTokenizerFactory " />

空格分词，精确匹配。

< filter class =" solr.WordDelimiterFilterFactory " generateWordParts =" 1 " generateNumberParts =" 1 " catenateWords =" 1 " catenateNumbers =" 1 " catenateAll =" 0 " splitOnCaseChange =" 1 " />

在分词和匹配时，考虑 "-"连字符，字母数字的界限，非字母数字字符，这样 "wifi"或"wi fi"都能匹配"Wi-Fi"。

< filter class =" solr.SynonymFilterFactory " synonyms =" synonyms.txt " ignoreCase =" true " expand =" true " />

同义词 

< filter class =" solr.StopFilterFactory " ignoreCase =" true " words =" stopwords.txt " enablePositionIncrements =" true " />

在禁用字（stopword）删除后，在短语间增加间隔

stopword：即在建立索引过程中（建立索引和搜索）被忽略的词，比如is this等常用词。在conf/stopwords.txt维护。

4、fields

< field name =" id " type =" string " indexed =" true " stored =" true " required =" true " />

• name：标识而已。
• type：先前定义的类型。
• indexed：是否被用来建立索引（关系到搜索和排序）
• stored：是否储存
• compressed：[false]，是否使用gzip压缩（只有TextField和StrField可以压缩）
• mutiValued：是否包含多个值
• omitNorms：是否忽略掉Norm，可以节省内存空间，只有全文本field和need an index-time boost的field需要norm。（具体没看懂，注释里有矛盾）
• termVectors：[false]，当设置true，会存储 term vector。当使用MoreLikeThis，用来作为相似词的field应该存储起来。
• termPositions：存储 term vector中的地址信息，会消耗存储开销。
• termOffsets：存储 term vector 的偏移量，会消耗存储开销。
• default：如果没有属性需要修改，就可以用这个标识下。

< field name =" text " type =" text " indexed =" true " stored =" false " multiValued =" true " />

包罗万象（有点夸张）的field，包含所有可搜索的text fields，通过copyField实现。

< copyField source =" cat " dest =" text " />

在添加索引时，将所有被拷贝field（如cat）中的数据拷贝到text field中

作用：

• 将多个field的数据放在一起同时搜索，提供速度
• 将一个field的数据拷贝到另一个，可以用2种不同的方式来建立索引。

< dynamicField name =" *_i " type =" int " indexed =" true " stored =" true " />

如果一个field的名字没有匹配到，那么就会用动态field试图匹配定义的各种模式。

• "*"只能出现在模式的最前和最后
• 较长的模式会被先去做匹配
• 如果2个模式同时匹配上，最先定义的优先

< dynamicField name =" * " type =" ignored " multiValued=" true " />

如果通过上面的匹配都没找到，可以定义这个，然后定义个type，当String处理。（一般不会发生）

但若不定义，找不到匹配会报错。

5、其他一些标签

< uniqueKey > id </ uniqueKey >

文档的唯一标识， 必须填写这个field（除非该field被标记required="false"），否则solr建立索引报错。

< defaultSearchField > text </ defaultSearchField >

如果搜索参数中没有指定具体的field，那么这是默认的域。

< solrQueryParser defaultOperator =" OR " />

配置搜索参数短语间的逻辑，可以是"AND|OR"。

二、solrconfig.xml

1、索引配置

mainIndex 标记段定义了控制Solr索引处理的一些因素.

• useCompoundFile：通过将很多 Lucene 内部文件整合到单一一个文件来减少使用中的文件的数量。这可有助于减少 Solr 使用的文件句柄数目，代价是降低了性能。除非是应用程序用完了文件句柄，否则 false 的默认值应该就已经足够。

• useCompoundFile：通过将很多Lucene内部文件整合到一个文件，来减少使用中的文件的数量。这可有助于减少Solr使用的文件句柄的数目，代价是降低了性能。除非是应用程序用完了文件句柄，否则false的默认值应该就已经足够了。
• mergeFacor：决定Lucene段被合并的频率。较小的值（最小为2）使用的内存较少但导致的索引时间也更慢。较大的值可使索引时间变快但会牺牲较多的内存。（典型的时间与空间 的平衡配置）
• maxBufferedDocs：在合并内存中文档和创建新段之前，定义所需索引的最小文档数。段是用来存储索引信息的Lucene文件。较大的值可使索引时间变快但会牺牲较多内存。
• maxMergeDocs：控制可由Solr合并的 Document 的最大数。较小的值（<10,000）最适合于具有大量更新的应用程序。
• maxFieldLength：对于给定的Document，控制可添加到Field的最大条目数，进而阶段该文档。如果文档可能会很大，就需要增加这个数值。然后，若将这个值设置得过高会导致内存不足错误。
• unlockOnStartup：告知Solr忽略在多线程环境中用来保护索引的锁定机制。在某些情况下，索引可能会由于不正确的关机或其他错误而一直处于锁定，这就妨碍了添加和更新。将其设置为true可以禁用启动索引，进而允许进行添加和更新。（锁机制）

 2、查询处理配置

query标记段中以下一些与缓存无关的特性：

• maxBooleanClauses：定义可组合在一起形成以个查询的字句数量的上限。正常情况1024已经足够。如果应用程序大量使用了通配符或范围查询，增加这个限制将能避免当值超出时，抛出TooMangClausesException。
• enableLazyFieldLoading：如果应用程序只会检索Document上少数几个Field，那么可以将这个属性设置为 true。懒散加载的一个常见场景大都发生在应用程序返回一些列搜索结果的时候，用户常常会单击其中的一个来查看存储在此索引中的原始文档。初始的现实常常只需要现实很短的一段信息。若是检索大型的Document，除非必需，否则就应该避免加载整个文档。

query部分负责定义与在Solr中发生的时间相关的几个选项：

概念：Solr（实际上是Lucene）使用称为Searcher的Java类来处理Query实例。Searcher将索引内容相关的数据加载到内存中。根据索引、CPU已经可用内存的大小，这个过程可能需要较长的一段时间。要改进这一设计和显著提高性能，Solr引入了一张“温暖”策略，即把这些新的Searcher联机以便为现场用户提供查询服务之前，先对它们进行“热身”。

• newSearcher和firstSearcher事件，可以使用这些事件来制定实例化新Searcher或第一个Searcher时，应该执行哪些查询。如果应用程序期望请求某些特定的查询，那么在创建新Searcher或第一个Searcher时就应该反注释这些部分并执行适当的查询。

query中的智能缓存：

• filterCache：通过存储一个匹配给定查询的文档 id 的无序集，过滤器让 Solr 能够有效提高查询的性能。缓存这些过滤器意味着对Solr的重复调用可以导致结果集的快速查找。更常见的场景是缓存一个过滤器，然后再发起后续的精炼查询，这种查询能使用过滤器来限制要搜索的文档数。
• queryResultCache：为查询、排序条件和所请求文档的数量缓存文档 id 的有序集合。
• documentCache：缓存Lucene Document，使用内部Lucene文档id（以便不与Solr唯一id相混淆）。由于Lucene的内部Document id 可以因索引操作而更改，这种缓存不能自热。
• Named caches：命名缓存是用户定义的缓存，可被 Solr定制插件 所使用。

其中filterCache、queryResultCache、Named caches（如果实现了org.apache.solr.search.CacheRegenerator）可以自热。

每个缓存声明都接受最多四个属性：

• class：是缓存实现的Java名
• size：是最大的条目数
• initialSize：是缓存的初始大小
• autoWarmCount：是取自旧缓存以预热新缓存的条目数。如果条目很多，就意味着缓存的hit会更多，只不过需要花更长的预热时间。

对于所有缓存模式而言，在设置缓存参数时，都有必要在内存、cpu和磁盘访问之间进行均衡。统计信息管理页（管理员界面的Statistics）对于分析缓存的 hit-to-miss 比例以及微调缓存大小的统计数据都非常有用。而且，并非所有应用程序都会从缓存受益。实际上，一些应用程序反而会由于需要将某个永远也用不到的条目存储在缓存中这一额外步骤而受到影响。

Having at hand a sample data of the albums and performers, I decided to show my way of dealing with such cases. For simplicity and clarity, I assume that after the first import, the data can only decrease.

Test data

My test data are located in the PostgreSQL database table defined as follows:

Table "public.albums"
Column |  Type   |                      Modifiers
--------+---------+-----------------------------------------------------
id     | integer | not null default nextval('albums_id_seq'::regclass)
name   | text    | not null
author | text    | not null
Indexes:
"albums_pk" PRIMARY KEY, btree (id)

The table has 825,661 records.

Test installation

For testing purposes I used the Solr instance having the following characteristics:

Definition at schema.xml:

Deleting Data

Looking at the table shows that when we remove the record, he is deleted without leaving a trace, and the only way to update our index would be to compare the documents identifiers in the index to the identifiers in the database and deleting those that no longer exist in the database. Slow and cumbersome. Another way is adding a column deleted_at: instead of physically deleting the record, only add information to this column. DIH can then retrieve all records from the set date later than the last crawl. The disadvantage of this solution may be necessary to modify the application to take such information into consideration.

I apply a different solution, transparent to applications. Let’s create a new table:

This table will automagically add an identifier of those items that were removed from the table albums and information when they were removed.

Now we add the function:

and a trigger:

How it works

Each entry deleted from the albums table should result in addition to the table deletes. Let’s check it out. Remove a few records:

So the database part works.

We fill up the DIH configuration file so that the entity has been defined as follows:

This allows the import DIH incremental import to use the deletedPkQuery attribute to get the identifiers of the documents which should be removed.

A clever reader will probably begin to wonder, are you sure we need the column with the date of deletion. We could delete all records that are found in the table deletes and then delete the contents of this table. Theoretically this is true, but in the event of a problem with the Solr indexing server we can easily replace it with another – the degree of synchronization with the database is not very important – just the next incremental imports will sync with the database. If we would delete the contents of the deletes table such possibility does not exist.

We can now do the incremental import by calling the following address:  /solr/dataimport?command=delta-import
In the logs you should see a line similar to this:
INFO: {delete=[35, 36],optimize=} 0 2
Which means that DIH properly removed from the index the documents, which were previously removed from the database.

大家知道在解压开solr的web程序（apache-solr-3.2.0.war）时，在其WEB-INF/lib目录下有slf4j- api-1.5.5.jar，slf4j-jdk14-1.5.5.jar这两个jar包，故可知其默认使用的是jdk的日志数据，其日志都是输入到 tomcat的logs中；再看其是结合slf4j进行jdk的日志数据；slf4j并不是一种具体的日志系统，而是一个用户日志系统的facade，允许在部署最终应用时方便的变更其日志系统。故solr使用log4j也是ok的，即采用log4j替换jdk的日志输入；做法如下：
1.  将solr/WINF-WEB/lib中的slf4j-api-1.5.5.jar，slf4j-jdk14-1.5.5.jar删除，新加入 log4j-1.2.15.jar  slf4j-api-1.5.0.jar  slf4j-log4j12-1.5.0.jar或是其对应的jar包；
2.在solr/WEB-INF/下创建classes目录，因为默认的包中没有该目录，其都是使用jsp操作；
3. 将写好的log4j.properties放到solr/WEB-INF/classes中, 其内容如下，

log4j.rootLogger=INFO
log4j.logger.org.apache.solr=INFO,ROLLING_FILE

log4j.appender.ROLLING_FILE=org.apache.log4j.RollingFileAppender
log4j.appender.ROLLING_FILE.Append=false
log4j.appender.ROLLING_FILE.File=/var/log/solr.log
log4j.appender.ROLLING_FILE.MaxBackupIndex=50
log4j.appender.ROLLING_FILE.MaxFileSize=200MB
log4j.appender.LOGFILE.Threshold=INFO
log4j.appender.ROLLING_FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLING_FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH\:mm\:ss} %p [%c]\:%L Line – %m%n

4.重启tomcat即可
PS：如果是采用JNDI部署，最好将以上的重新打包war，在替换旧的

约定:
1.读者应具备一定JAVA的知识.

2.本文中的JVM选项均以SUN公司发布的HotSpot JVM 5为准（不过大多数的选项在JVM1.3,JVM1.4中也是可用的）.

3.以JAVA_HOME下demo/jfc/SwingSet2/SwingSet2.jar为例进行说明.

4.阅读本文需要一些关于GC的知识，可以到附录A中了解这些知识。

关键字:
JVM(java虚拟机),调优,GC(垃圾回收)

JVM GC调优
为了能够将JVM GC的调优能够使用在具体的实践当中,下面将利用若干个例子来说明GC的调优.
例1：Heap size 设置
JVM堆的设置是指java程序运行过程中JVM可以调配使用的内存空间的设置.JVM在启动的时候会自动设置Heap size的值，其初始空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等选项可进行设置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
当在JAVA_HOME下demo/jfc/SwingSet2/目录下执行下面的命令。
java -jar -Xmn4m -Xms16m -Xmx16m SwingSet2.jar
系统输出为：
Exception in thread "Image Fetcher 0" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 3" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 1" java.lang.OutOfMemoryError: Java heap space
Exception in thread "Image Fetcher 2" java.lang.OutOfMemoryError: Java heap space
除了这些异常信息外，还会发现程序的响应速度变慢了。这说明Heap size 设置偏小，GC占用了更多的时间，而应用分配到的执行时间较少。
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。
将上面的命令换成以下命令执行则应用能够正常使用，且未抛出任何异常。
java -jar -Xmn4m -Xms16m -Xmx32m SwingSet2.jar
提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。

例2：Young Generation（-Xmn）的设置
在本例中看一下Young Generation的设置不同将有什么现象发生。
假设将Young generation 的大小设置为4M ，即执行java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar，屏幕输出如下（节选）
[GC [DefNew: 3968K->64K(4032K), 0.0923407 secs] 3968K->2025K(32704K), 0.0931870 secs]
[GC [DefNew: 4021K->64K(4032K), 0.0356847 secs] 5983K->2347K(32704K), 0.0365441 secs]
[GC [DefNew: 3995K->39K(4032K), 0.0090603 secs] 6279K->2372K(32704K), 0.0093377 secs]
[GC [DefNew: 3992K->23K(4032K), 0.0057540 secs] 6325K->2356K(32704K), 0.0060290 secs]
[GC [DefNew: 3984K->27K(4032K), 0.0013058 secs] 6317K->2360K(32704K), 0.0015888 secs]
[GC [DefNew: 3981K->59K(4032K), 0.0023307 secs] 6315K->2422K(32704K), 0.0026091 secs]
将程序体制并将Young Generation的大小设置为8M，即执行java -jar -verbose:gc -Xmn8m -Xms32m -Xmx32m -XX:+PrintGCDetails SwingSet2.jar，屏幕输出如下（节选）
[GC [DefNew: 7808K->192K(8000K), 0.1016784 secs] 7808K->2357K(32576K), 0.1022834 secs]
[GC [DefNew: 8000K->70K(8000K), 0.0149659 secs] 10165K->2413K(32576K), 0.0152557 secs]
[GC [DefNew: 7853K->59K(8000K), 0.0069122 secs] 10196K->2403K(32576K), 0.0071843 secs]
[GC [DefNew: 7867K->171K(8000K), 0.0075745 secs] 10211K->2681K(32576K), 0.0078376 secs]
[GC [DefNew: 7970K->192K(8000K), 0.0201353 secs] 10480K->2923K(32576K), 0.0206867 secs]
[GC [DefNew: 7979K->30K(8000K), 0.1787079 secs] 10735K->4824K(32576K), 0.1790065 secs]
那么根据GC输出的信息（这里取第一行）做一下Minor收集的比较。可以看出两次的Minor收集分别在Young generation中找回3904K（3968K->64K）和7616K(7808K->192K)而对于整个jvm则找回1943K（3968K->2025）和5451K（7808K->2357K）。第一种情况下Minor收集了大约50％（1943/3904）的对象，而另外的50％的对象则被移到了tenured generation。在第二中情况下Minor收集了大约72％的对象，只有不到30％的对象被移到了Tenured Generation.这个例子说明此应用在的Young generation 设置为4m时显的偏小。
提示：一般的Young Generation的大小是整个Heap size的1/4。Young generation的minor收集率应一般在70％以上。当然在实际的应用中需要根据具体情况进行调整。

例3：Young Generation对应用响应的影响
还是使用-Xmn4m 和-Xmn8m进行比较，先执行下面的命令

java -jar -verbose:gc -Xmn4m -Xms32m -Xmx32m -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime SwingSet2.jar
屏幕输出如下（节选）
Application time: 0.5114944 seconds
[GC [DefNew: 3968K->64K(4032K), 0.0823952 secs] 3968K->2023K(32704K), 0.0827626 secs]
Total time for which application threads were stopped: 0.0839428 seconds
Application time: 0.9871271 seconds
[GC [DefNew: 4020K->64K(4032K), 0.0412448 secs] 5979K->2374K(32704K), 0.0415248 secs]
Total time for which application threads were stopped: 0.0464380 seconds
Young Generation 的Minor收集占用的时间可以计算如下：应用线程被中断的总时常/（应用执行总时?L+应用线程被中断的总时常），那么在本例中垃圾收集占用的时?L约为系统的5％~14％。那么当垃圾收集占用的时间的比例越大的时候，系统的响应将越慢。
提示：对于互联网应用系统的响应稍微慢一些，用户是可以接受的，但是对于GUI类型的应用响应速度慢将会给用户带来非常不好的体验。

例4：如何决定Tenured Generation 的大小
分别以-Xmn8m -Xmx32m和-Xmn8m -Xmx64m进行对比，先执行
java -verbose:gc -Xmn8m -Xmx32m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类，命令行将提示（只提取了Major收集）

111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]
122.463: [GC 122.463: [DefNew: 8128K->8128K(8128K), 0.0000560 secs]122.463: [Tenured: 18630K->2366K(24576K), 0.1322560 secs] 26758K->2366K(32704K), 0.1325284 secs]
133.896: [GC 133.897: [DefNew: 8128K->8128K(8128K), 0.0000443 secs]133.897: [Tenured: 18240K->2573K(24576K), 0.1340199 secs] 26368K->2573K(32704K), 0.1343218 secs]
144.112: [GC 144.112: [DefNew: 8128K->8128K(8128K), 0.0000544 secs]144.112: [Tenured: 16564K->2304K(24576K), 0.1246831 secs] 24692K->2304K(32704K), 0.1249602 secs]
再执行java -verbose:gc -Xmn8m -Xmx64m-XX:+PririntGCDetails -XX:+PrintGCTimeStamps java类，命令行将提示（只提取了Major收集）
90.597: [GC 90.597: [DefNew: 8128K->8128K(8128K), 0.0000542 secs]90.597: [Tenured: 49841K->5141K(57344K), 0.2129882 secs] 57969K->5141K(65472K), 0.2133274 secs]
120.899: [GC 120.899: [DefNew: 8128K->8128K(8128K), 0.0000550 secs]120.899: [Tenured: 50384K->2430K(57344K), 0.2216590 secs] 58512K->2430K(65472K), 0.2219384 secs]
153.968: [GC 153.968: [DefNew: 8128K->8128K(8128K), 0.0000511 secs]153.968: [Tenured: 51164K->2309K(57344K), 0.2193906 secs] 59292K->2309K(65472K), 0.2196372 secs]
可以看出在Heap size 为32m的时候系统等候时间约为0.13秒左右，而设置为64m的时候等候时间则增大到0.22秒左右了。但是在32m的时候系统的Major收集间隔为10秒左右，而Heap size 增加到64m的时候为30秒。那么应用在运行的时候是选择32m还是64m呢？如果应用是web类型（即要求有大的吞吐量）的应用则使用64m（即heapsize大一些）的比较好。对于要求实时响应要求较高的场合（例如GUI型的应用）则使用32m比较好一些。 
注意：
1。因为在JVM5运行时已经对Heap-size进行了优化，所以在能确定java应用运行时不会超过默认的Heap size的情况下建议不要对这些值进行修改。
2。Heap size的 -Xms -Xmn 设置不要超出物理内存的大小。否则会提示“Error occurred during initialization of VM Could not reserve enough space for object heap”。

例5:如何缩短minor收集的时间
下面比较一下采用-XX:+UseParNewGC选项和不采用它的时候的minor收集将有什么不同。先执行
java -jar -server -verbose:gc -Xmn8m -Xms32m -Xmx32m SwingSet2.jar 
系统将输出如下信息（片段〕
[GC 7807K->2641K(32576K), 0.0676654 secs]
[GC 10436K->3108K(32576K), 0.0245328 secs]
[GC 10913K->3176K(32576K), 0.0072865 secs]
[GC 10905K->4097K(32576K), 0.0223928 secs]
之后再执行 java -jar -server -verbose:gc -XX:+UseParNewGC -Xmn8m -Xms32m -Xmx32m SwingSet2.jar
系统将输出如下信息（片段〕
[ParNew 7808K->2656K(32576K), 0.0447687 secs]
[ParNew 10441K->3143K(32576K), 0.0179422 secs]
[ParNew 10951K->3177K(32576K), 0.0031914 secs]
[ParNew 10985K->3867K(32576K), 0.0154991 secs]
很显然使用了-XX:+UseParNewGC选项的minor收集的时间要比不使用的时候优。

例6:如何缩短major收集的时间
下面比较一下采用-XX:+UseConcMarkSweepGC选项和不采用它的时候的major收集将有什么不同。先执行
java -jar -verbose:gc -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息（片段〕
[Full GC 22972K->18690K(262080K), 0.2326676 secs]
[Full GC 18690K->18690K(262080K), 0.1701866 secs
之后再执行 java -jar -verbose:gc -XX:+UseParNewGC -Xmn64m -Xms256m -Xmx256m SwingSet2.jar
系统将输出如下信息（片段〕
[Full GC 56048K->18869K(260224K), 0.3104852 secs]
提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适。

例7:关于-server选项 在JVM中将运行中的类认定为server-class的时候使用此选项。SUN 的Hot Spot JVM5 如果判断到系统的配置满足如下条件则自动将运行的类认定为server-class，并且会自动设置jvm的选项（当没有手工设置这选项的时候〕而且HOTSPOT JVM5提供了自动调优的功能，他会根据JVM的运行情况进行调整。如果没有特别的需要是不需要太多的人工干预的。SUN形象的称这个机制为“人体工学”（Ergonomics〕。具体可以参考http://java.sun.com/docs/hotspot/gc5.0/ergo5.html
*.具有2个或更多个物理的处理器
*.具有2G或者更多的物理内存
提示：此选项要放在所有选项的前面。例如：java -server 其他选项 java类

附录A:预备知识
．JVM中对象的划分及管理

JVM根据运行于其中的对象的生存时间大致的分为3种。并且将这3种不同的对象分别存放在JVM从系统分配到的不同的内存空间。这种对象存放空间的管理方式叫做Generation管理方式。
1。Young Generation：用于存放“早逝”对象（即瞬时对象）。例如：在创建对象时或者调用方法时使用的临时对象或局部变量。
2。Tenured Generation：用于存放“驻留”对象（即较长时间被引用的对象）。往往体现为一个大型程序中的全局对象或长时间被使用的对象。
3。Perm Generation：用于存放“永久”对象。这些对象管理着运行于JVM中的类和方法。

．JVM选项的分类

JVM有这么几种选项供使用.
1.供-X选项使用的项目,又称为非标准选项，不同厂商的此类型选项是有所不同的。例如：IBM的JVM用的一些选项在Sun的JVM中就不一定能生效。这种选项的使用方式如下:
java -Xmn16m -Xms64m -Xmx64m java类名
2.供-XX选项使用的项目，这种类型的选项可能要求有对系统信息访问的权限。所以要慎用。这种选项的使用方式如下:
java -XX:MaxHeapFreeRatio=70 -XX:+PrintGCDetails java类名
3.java选项(即在命令行执行java后提示的选项).
java -server -verbose:gc -d64 java类名

．垃圾收集分类

在JVM中有两种垃圾方式，一种叫做Minor（次收集），另一种叫做Major（主收集）。其中Minor在Young Generation的空间被对象全部占用后执行，主要是对Young Generation中的对象进行垃圾收集。而Major是针对于整个Heap size的垃圾收集。其中Minor方式的收集经常发生，并且Minor收集所占用的系统时间小。Major方式的垃圾收集则是一种“昂贵”的垃圾收集方式，因为在Major要对整个Heap size进行垃圾收集,这会使得应用停顿的时间变得较长。

．GC信息的格式

[GC [<collector>: <starting occupancy1> -> <ending occupancy1>, <pause time1> secs] <starting occupancy3> -> <ending occupancy3>, <pause time3> secs]
<collector> GC为minor收集过程中使用的垃圾收集器起的内部名称.
<starting occupancy1> young generation 在进行垃圾收集前被对象使用的存储空间.
<ending occupancy1> young generation 在进行垃圾收集后被对象使用的存储空间
<pause time1> minor收集使应用暂停的时间长短(秒) 
<starting occupancy3> 整个堆(Heap Size)在进行垃圾收集前被对象使用的存储空间
<ending occupancy3> 整个堆(Heap Size)在进行垃圾收集后被对象使用的存储空间
<pause time3> 整个垃圾收集使应用暂停的时间长短(秒),包括major收集使应用暂停的时间(如果发生了major收集).
．GC信息的选项
-XX:+PrintGCDetails 显示GC的详细信息
-XX:+PrintGCApplicationConcurrentTime 打印应用执行的时间
-XX:+PrintGCApplicationStoppedTime 打印应用被暂停的时间
提示:1.":"后的"+"号表示开启此选项,如果是"-"号那么表示关闭此选项。
     2.在不同的选项和不同的收集方式和类型下输出的格式会有所不同。

       1. jstat -gc pid

            可以显示gc的信息，查看gc的次数，及时间。

            其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。

      2.jstat -gccapacity pid
            可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，

            如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，

            PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。

            其他的可以根据这个类推， OC是old内纯的占用量。

     3.jstat -gcutil pid

            统计gc信息统计。

     4.jstat -gcnew pid

           年轻代对象的信息。

     5.jstat -gcnewcapacity pid

           年轻代对象的信息及其占用量。

     6.jstat -gcold pid

          old代对象的信息。

     7.stat -gcoldcapacity pid

          old代对象的信息及其占用量。

     8.jstat -gcpermcapacity pid

          perm对象的信息及其占用量。

     9.jstat -class pid

          显示加载class的数量，及所占空间等信息。
     10.jstat -compiler pid

          显示VM实时编译的数量等信息。

     11.stat -printcompilation pid

          当前VM执行的信息。

        一些术语的中文解释：

         S0C：年轻代中第一个survivor（幸存区）的容量 (字节)
         S1C：年轻代中第二个survivor（幸存区）的容量 (字节)
         S0U：年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
         S1U：年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
           EC：年轻代中Eden（伊甸园）的容量 (字节)
           EU：年轻代中Eden（伊甸园）目前已使用空间 (字节)
           OC：Old代的容量 (字节)
           OU：Old代目前已使用空间 (字节)
           PC：Perm(持久代)的容量 (字节)
           PU：Perm(持久代)目前已使用空间 (字节)
         YGC：从应用程序启动到采样时年轻代中gc次数
       YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
         FGC：从应用程序启动到采样时old代(全gc)gc次数
       FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
         GCT：从应用程序启动到采样时gc用的总时间(s)

    NGCMN：年轻代(young)中初始化(最小)的大小 (字节)

    NGCMX：年轻代(young)的最大容量 (字节)

        NGC：年轻代(young)中当前的容量 (字节)

   OGCMN：old代中初始化(最小)的大小 (字节)

   OGCMX：old代的最大容量 (字节)

       OGC：old代当前新生成的容量 (字节)

   PGCMN：perm代中初始化(最小)的大小 (字节)

   PGCMX：perm代的最大容量 (字节)  

       PGC：perm代当前新生成的容量 (字节)

          S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

         S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

           E：年轻代中Eden（伊甸园）已使用的占当前容量百分比

           O：old代已使用的占当前容量百分比

           P：perm代已使用的占当前容量百分比

  S0CMX：年轻代中第一个survivor（幸存区）的最大容量 (字节)

 S1CMX ：年轻代中第二个survivor（幸存区）的最大容量 (字节)

    ECMX：年轻代中Eden（伊甸园）的最大容量 (字节)

       DSS：当前需要survivor（幸存区）的容量 (字节)（Eden区已满）

          TT： 持有次数限制

       MTT ： 最大持有次数限制

可是在XHTML中, 如果body 体中只有一行, 则document.body.clientHeight 只能取到那一行的高度, 约20px, 这时如何还想取到整个页面的高度, 就要用document.documentElement.clientHeight 来获取了.

原因是: 在HTML 中, body 是整个DOM 的根, 而在XHTML 中, document 才是根, body 不再是根, 所以取body 的属性时, 不能再取到整个页面的值.

区别新旧标准的行是:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN” >
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
前者指明该页面使用旧标准, 后者指明该页面使用新标准.

总结:
XHTML中用 document.documentElement.clientHeight 代替
document.body.clientHeight

           如何正确煎中药

    中药也叫中草药，是指中国传统医学中用以防病治病的物质，包括天然药及其加工品。虽然名义上叫中“草”药，是以草木类药物为主，也有动物药（包括龟、鳖、羊、虎等动物身体的一部分），昆虫药（包括蚯蚓、蜈蚣、土鳖虫等），矿物药（包括各种金属）。

    正是因为中药材疗效卓越，种类繁杂，每一味药材的性、状、质都不同，所以煎煮和服用的方法很独特。可以说煎煮和服用方法直接影响疗效，我们今天就来谈谈中药材合理的煎煮方法。 
    【步骤】

    一、先来学几个概念：“先煎”，“后下”，“包煎”，“另煎”，“冲服”，“解表药”，“补益药”，“一碗水”。
    1.先煎  就是要先打碎后煎煮20-30分钟以后再入其它药合煎到规定时间。需要先煎的药比较容易识别，它们都是些矿石及贝壳类药材，像石决明、牡蛎、磁石、龙骨等。

    2.后下  是指在其它药物煎好出锅前10分钟放入的药材。它们指那些含有芳香挥发物质的药物，久煎会损失药效，如薄荷、砂仁、蔻仁、佩兰、青蒿等，另外大黄、钩藤也宜后下。
提示：在滋补的方剂中往往会加入一些行气药，如青皮、陈皮、枳实、枳壳、砂仁、蔻仁等，我们建议这些也应该后下，煎煮10-15分钟后起锅，因为滋补药需要久煎，而这些药不耐久煎，也应该单独包装。

    3.包煎  是指某些需要装入纱布袋煎煮的药，这些药大多是粘性强、粉末状、颗粒细小或者是有绒毛的药材，如车前子、苏子、蛤粉、青黛、枇杷叶、旋覆花、蒲黄等，如不包煎服用时要滤清药液。

    4.另煎  是指一些贵重药材，为了更好地煎出有效成分并防止浪费，需要单独煎煮，其煎液可与其他药物的煎液合并后服用或单独服用，如野山参、高丽参、西洋参等；冬虫夏草另煎并连药材同吃，或磨粉冲服更好。

    5.冲服  是指某些特别贵重、量少的细料药可以磨成细粉，用其他药物煎好的汤药冲服，如珍珠、犀角、羚羊角、麝香、朱砂、三七、琥珀等；新鲜的中草药必要时也可以打汁冲服；天麻、鸡内金、炙甲珠研末冲服比入煎效果好。
    提示：
    ※需要按以上五种煎煮方法处理的药材在药房包装时，药剂师应该单独包装和详细告知顾客，这是规定也是起码的行业道德。当然也有个别药剂师没有尽到告知义务或根本不单独包装，这就需要我们自己留意。俗话说，多学点没坏处。

    6.解表药  是指治疗扁桃体炎、腮腺炎、流行性感冒、上呼吸道感染和因此而引起的头痛、咳嗽、鼻塞、发热、怕冷、咽痛等病症的方剂。

    7.补益药  是指治疗身体因脏腑疾病造成的慢性损耗、劳倦外伤或营养不良引起的阴阳气血津液的不足而致虚的方剂。也许理解起来很困难，但补益药有个特征，就是往往包含有这么几种药——人参、党参、黄芪、白术、生地、熟地、当归、枸杞、麦冬、山萸、肉苁蓉、杜仲、补骨脂等，如果看到这几种药就可以断定这张方剂有补益的作用，但不一定是单纯的补益，往往是攻补结合或通补结合的。

    8.一碗水  大概相当于半斤牛奶的量。

    二、准备煎药了。
    1.什么工具最合适？
    首选砂锅，砂锅材质性质稳定，不宜与药物中的化学物质结合，而且受热均匀；其次是陶瓷或搪瓷器皿；不锈钢或铝锅也可以，只是所用的锅要有盖子。切记忌用铁锅和铜锅。另外准备一把长柄勺子，勺子大小依药物多少而定，因为勺子比筷子容易翻底。

用水注意一点，煎药用自来水即可，只是要用新鲜的生水，有条件就不要用热水、凉开水和久沸的水。
    提示：
    ※头煎必须加冷水，接着煎二煎必须加热水，因为药物中的蛋白质遇冷会凝结。

    先浸泡一下。这一步很重要。刚买回来的干燥的药材加水不要太多，水面高出1横指就行，这样过一段时间，水就被药物吸收了，煎药前把水补足就可以。中草药在煎煮以前必须要经过充分浸泡以利于有效成分煎出。可惜的是现在代客煎药的药房最多浸泡30分钟，甚至根本不浸泡就直接下锅了，所以我们建议如果有条件就自己煎。
    提示：
    ※如果万一加水多了，就在头煎开锅以前盛出一些，二煎再用，开锅以后就不要这样了。

    那么30分钟到底够不够？一般来说是够了，解表药只需浸泡20分钟就可以，因为解表药往往是花、茎、叶等质轻的药，比较容易吃水；补益药的浸泡时间要长一点，有人说60分钟就可以了，但实际情况看，有些块状或片状的药往往需要2个小时才能吃饱水，比如生地、熟地、麦冬、白术这些药，尤其是加工不精细，块比较大的时候更是如此。
    提示：
    ※如果是急救药，不要泥于以上规则，直接下锅好了，救命要紧。
    ※“先煎”，“后下”的药物要单独浸泡，“包煎”不需要单独浸泡。

    2.该放多少水？
    这里有一个原则：补益药要多放水、久煎、取浓汁；其它药少放水、轻煎、多取汁。
    解释一下，要在充分浸泡以后加水，补益药头煎水面高出3横指，二煎刚刚没过药物；解表药头煎加水过1指，二煎没过药物；其它药头煎高出1横指，二煎没过药物。这里有个前提，就是总水量多于2碗。如果药物很少，总水量不足2碗，那就加2碗水，煎到1碗就可以了。总之，头煎药液浓，水要多些，二煎药液淡，水就少些。
    提示：
    ※不要在煎药中途加水，尤其是时间过半了以后再加水就只能是稀释药液而已，所以要一次加水加足。开始不好掌握，万不得已时水多点总比少点好。中医有句古语——药服满浆，意即服药要服够量，水太少了药物作用小。
    ※如果每服药医嘱是一天服两遍，要保证每服药至少煎出2碗水，服三遍则三碗水。

    三、可以煎药了
    1.该煎多长时间？
    补益药头煎要50分钟，二煎要30分钟；解表药头煎要15分钟，二煎要10分钟；其它药头煎30分钟，二煎15分钟就可以了。
    提示：
    ※每服药要煎两遍，因为每味药材的煎出时间不同，煎两遍才能保证全部煎出。如果煎药前充分浸泡过，并且煎药时间足够，可以不煎第三遍。
    ※现在的药店都搞一刀切，统统告诉顾客头煎20分钟，二煎15分钟，这是不科学的。之所以这么告诉顾客，是因为该单包的不单包，该后下的就不能后下了，就只能煎20分钟了，因为行气药不耐久煎，所以自己要注意一下。

    2.掌握好火候。
    煎药就像烹饪，火候很重要。开始时要大火，开锅后转小火，让水轻轻沸腾就可以，火太大有效成分就会过多蒸发，二煎同样。煎药的过程中要隔10几分钟把药由下至上彻底翻一遍，尤其是二煎水比较少时更重要。
    提示：
    ※不要忘记对药物“先煎”，“后下”，“包煎”，“另煎”，“冲服”的下锅时间掌握。

    四、怎么储存汤药
    煎好的药液就是可以服用的汤药了，由于没有添加任何防腐剂，所以时间久了会变质，原则上是当天煎当天服。但是每天都煎药时间不允许，我们可以变通一下，一次煎4-7服药，把药液保存在冰箱冷藏室内，7天之内是不会变质的。服用的时候盛出一碗，在微波炉加热3-4分钟或者火上稍微烧开。
    提示：
    ※除非有医嘱，否则所有汤药都不能冷服，每次服药前都要稍微烧开，然后温度合适了再喝，因为中药的有效成分都是加热了以后才能相互融合。

    另外，有人总认为水煎药材一定是三、四碗水煮成一碗。其实不然，由于水煎药材的成分不同、煎煮的方法当然要“因药而异”，才能充分发挥每味药材的药效；临床上，常见的药材煎煮法有下列几种：

　　1. 标准煮法：药材为一般的补药(例如包含有当归、黄芪、熟地)

　　步骤一：先将药材放入锅内(不可使用铁锅或铜锅)，加入适量的水(超过药面约2公分、大约4碗水)，浸泡半个小时。

　　步骤二：以武火(大火)煮沸后，再以文火(小火)煮到剩一碗水(约250ml.)，将煮好的药液倒出于碗中，再重复用三碗水煎煮成8分，前后两次混合服用。

　　2. 快煮法：药材含有挥发性中药(例如银花、菊花等治疗感冒的中药)

　　步骤一：先将药材放入锅内，加入适量的水(刚好盖过药面，约三碗水)，浸泡半个小时。

　　步骤二：以武火(大火)煮沸后，再以文火(小火)煮10分钟，不可打开盖子，煮一次即可服用，不必重复一次。

　　3. 后下法：药材中含有不耐煮的中药(例如天麻、钩藤、麻黄等)

　　步骤一：先用四碗水浸泡药材约半个小时。

　　步骤二：以武火(大火)煮沸后，再以文火(小火)煮到剩一碗水(约250ml.)时，再将不耐煮的中药(一般会另外包)投入再煮5分钟，将药液倒出于碗中即可服用。

　　4. 先下法：药材中有一些需久煮的矿物类(例如：滑石、石膏)。

　　步骤一：先将矿物类的中药(另外包)加入六碗水，先煎30分钟后，再加入其它药材。

　　步骤二：以武火(大火)煮沸后，再以文火(小火)煮到剩一碗水(约250ml.)，将煮好的药液倒出于碗中服用即可。

　　5. 另煎法：药材中含有一些名贵药材(例如人参)

　　步骤一：先将一般药材加四碗水放入锅内，浸泡半个小时，大火煮沸后，小火煮到剩一碗水，放凉。

　　步骤二：将名贵药材的药材，加一碗水，于电饭锅中蒸30分钟后，取出与上述药液相混，即可服用。

　　“良药苦口”，中药本来就不太好吃，何况是水煎中药？可是，如果真的病情需要服用水煎中药，那么，至少也要“料理”正确、水药的药效才会彻底出来，所以，如果有机会服用水煎中药时，别忘了问问您的医师、该如何煎煮您的中药，可不是一味地“三、四碗煮成一碗”！

相关博文链接：

      李老传艺：http://blog.sina.com.cn/s/articlelist_1390170500_8_1.html

      学道从师：http://blog.sina.com.cn/s/articlelist_1390170500_4_1.html

      华夏中医：http://blog.sina.com.cn/s/articlelist_1390170500_1_1.html

      原创歌曲：http://blog.sina.com.cn/s/articlelist_1390170500_3_1.html

      北京奥运：http://blog.sina.com.cn/s/articlelist_1390170500_10_1.html（百年梦圆）

    5.12地震：http://blog.sina.com.cn/s/articlelist_1390170500_2_1.html （不堪回首）

      中医普及宣传专辑：http://blog.sina.com.cn/s/articlelist_1390170500_7_1.html   

首先当然是得到log4j的jar档，推荐使用1.2.X版，下载地址：

http://logging.apache.org/log4j/1.2/download.html

我们先看一个最简单的示例：

【示例1】

项目结构：

【注：由于这里的多个项目公用一个jar档，我们可以创建一个专门放置jar档的Java工程，然后将jar档放到lib目录下。在要使用的工程中按图所示进行引用 】

 配置文件log4j.properties:

通过配置文件可知，我们需要配置3个方面的内容：

1、根目录（级别和目的地）；

2、目的地（控制台、文件等等）；

3、输出样式。

下面我们来看看Log4J的类图：

Logger - 日志写出器，供程序员输出日志信息
Appender - 日志目的地，把格式化好的日志信息输出到指定的地方去
ConsoleAppender - 目的地为控制台的Appender
FileAppender - 目的地为文件的Appender
RollingFileAppender - 目的地为大小受限的文件的Appender
Layout - 日志格式化器，用来把程序员的logging request格式化成字符串
PatternLayout - 用指定的pattern格式化logging request的Layout

Log4j基本使用方法

　　Log4j由三个重要的组件构成：日志信息的优先级，日志信息的输出目的地，日志信息的输出格式。日志信息的优先级从高到低有ERROR、WARN、 INFO、DEBUG，分别用来指定这条日志信息的重要程度；日志信息的输出目的地指定了日志将打印到控制台还是文件中；而输出格式则控制了日志信息的显示内容。

　　一、定义配置文件

　　其实您也可以完全不使用配置文件，而是在代码中配置Log4j环境。但是，使用配置文件将使您的应用程序更加灵活。Log4j支持两种配置文件格式，一种是XML格式的文件，一种是Java特性文件（键=值）。下面我们介绍使用Java特性文件做为配置文件的方法：

　　1.配置根Logger，其语法为：

　　log4j.rootLogger = [ level ] , appenderName, appenderName, …

　　其中，level 是日志记录的优先级，分为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。Log4j建议只使用四个级别，优先级从高到低分别是ERROR、WARN、INFO、DEBUG。通过在这里定义的级别，您可以控制到应用程序中相应级别的日志信息的开关。比如在这里定义了INFO级别，则应用程序中所有DEBUG级别的日志信息将不被打印出来。 appenderName就是指B日志信息输出到哪个地方。您可以同时指定多个输出目的地。

　　2.配置日志信息输出目的地Appender，其语法为：

　　log4j.appender.appenderName = fully.qualified.name.of.appender.class
　　log4j.appender.appenderName.option1 = value1
　　…
　　log4j.appender.appenderName.option = valueN

　　其中，Log4j提供的appender有以下几种：
　　org.apache.log4j.ConsoleAppender（控制台），
　　org.apache.log4j.FileAppender（文件），
　　org.apache.log4j.DailyRollingFileAppender（每天产生一个日志文件），
　　org.apache.log4j.RollingFileAppender（文件大小到达指定尺寸的时候产生一个新的文件），
　　org.apache.log4j.WriterAppender（将日志信息以流格式发送到任意指定的地方）

　　3.配置日志信息的格式（布局），其语法为：

　　log4j.appender.appenderName.layout = fully.qualified.name.of.layout.class
　　log4j.appender.appenderName.layout.option1 = value1
　　…
　　log4j.appender.appenderName.layout.option = valueN

　　其中，Log4j提供的layout有以e几种：
　　org.apache.log4j.HTMLLayout（以HTML表格形式布局），
　　org.apache.log4j.PatternLayout（可以灵活地指定布局模式），
　　org.apache.log4j.SimpleLayout（包含日志信息的级别和信息字符串），
　　org.apache.log4j.TTCCLayout（包含日志产生的时间、线程、类别等等信息）

　　Log4J采用类似C语言中的printf函数的打印格式格式化日志信息，打印参数如下： %m 输出代码中指定的消息

　　%p 输出优先级，即DEBUG，INFO，WARN，ERROR，FATAL
　　%r 输出自应用启动到输出该log信息耗费的毫秒数
　　%c 输出所属的类目，通常就是所在类的全名
　　%t 输出产生该日志事件的线程名
　　%n 输出一个回车换行符，Windows平台为“rn”，Unix平台为“n”
　　%d 输出日志时间点的日期或时间，默认格式为ISO8601，也可以在其后指定格式，比如：%d{yyy MMM dd HH:mm:ss,SSS}，输出类似：2002年10月18日 22：10：28，921
　　%l 输出日志事件的发生位置，包括类目名、发生的线程，以及在代码中的行数。举例：Testlog4.main(TestLog4.java:10)

　　二、在代码中使用Log4j

　　1.得到记录器

　　使用Log4j，第一步就是获取日志记录器，这个记录器将负责控制日志信息。其语法为：

　　public static Logger getLogger( String name)

　　通过指定的名字获得记录器，如果必要的话，则为这个名字创建一个新的记录器。Name一般取本类的名字，比如：

　　static Logger logger = Logger.getLogger ( ServerWithLog4j.class.getName () )

　　2.读取配置文件

　　当获得了日志记录器之后，第二步将配置Log4j环境，其语法为：

　　BasicConfigurator.configure ()： 自动快速地使用缺省Log4j环境。
　　PropertyConfigurator.configure ( String configFilename) ：读取使用Java的特性文件编写的配置文件。
　　DOMConfigurator.configure ( String filename ) ：读取XML形式的配置文件。

　　3.插入记录信息（格式化日志信息）

　　当上两个必要步骤执行完毕，您就可以轻松地使用不同优先级别的日志记录语句插入到您想记录日志的任何地方，其语法如下：

　　Logger.debug ( Object message ) ;
　　Logger.info ( Object message ) ;
　　Logger.warn ( Object message ) ;
　　Logger.error ( Object message ) ;

示例2～示例8

【示例2】 输出为文本文件或HTML文件

【 示例3】 输出为文本文件或HTML文件

 输出结果：

DEBUG - This is debug message.
INFO - This is info message.
ERROR - This is error message.

【示例5】 自定义样式

#设置级别和目的地
log4j.rootLogger=debug,appender1

#输出到控制台
log4j.appender.appender1=org.apache.log4j.ConsoleAppender
#设置输出样式
log4j.appender.appender1.layout=org.apache.log4j.PatternLayout
#自定义样式
# %r 时间 0
# %t 方法名 main
# %p 优先级 DEBUG/INFO/ERROR
# %c 所属类的全名(包括包名)
# %l 发生的位置，在某个类的某行
# %m 输出代码中指定的讯息，如log(message)中的message
# %n 输出一个换行

log4j.appender.appender1.layout.ConversionPattern=%r [%t] [%p] - %c -%l -%m%n

输出结果：

1 0 [main] [DEBUG] - com.coderdream.log4j.HelloLog4j 
2 -com.coderdream.log4j.HelloLog4j.main(HelloLog4j.java:16) -This is debug message.
3 31 [main] [INFO] - com.coderdream.log4j.HelloLog4j 
4 -com.coderdream.log4j.HelloLog4j.main(HelloLog4j.java:18) -This is info message.
5 31 [main] [ERROR] - com.coderdream.log4j.HelloLog4j 
6 -com.coderdream.log4j.HelloLog4j.main(HelloLog4j.java:20) -This is error message.

【示例6】 多目的地、自定义样式

#设置级别和目的地
log4j.rootLogger=debug,appender1,appender2

#输出到控制台
log4j.appender.appender1=org.apache.log4j.ConsoleAppender
#设置输出样式
log4j.appender.appender1.layout=org.apache.log4j.PatternLayout
#自定义样式
# %r 时间 0
# %t 方法名 main
# %p 优先级 DEBUG/INFO/ERROR
# %c 所属类的全名(包括包名)
# %l 发生的位置，在某个类的某行
# %m 输出代码中指定的讯息，如log(message)中的message
# %n 输出一个换行符号
log4j.appender.appender1.layout.ConversionPattern=[%d{yy/MM/dd HH:mm:ss:SSS}][%C-%M] %m%n

#输出到文件(这里默认为追加方式)
log4j.appender.appender2=org.apache.log4j.FileAppender
#设置文件输出路径
#【1】文本文件
log4j.appender.appender2.File=c:/Log4JDemo06.log
#设置文件输出样式
log4j.appender.appender2.layout=org.apache.log4j.PatternLayout
log4j.appender.appender2.layout.ConversionPattern=[%d{HH:mm:ss:SSS}][%C-%M] -%m%n

【示例7】 【企业应用】设置 特定包的级别和目的地

先增加一个包，新建一个类：

package com.coderdream.log4jDao;

import org.apache.log4j.Logger;

public class HelloDao {
    private static Logger logger = Logger.getLogger(HelloDao.class);

    /**
     * @param args
     */
    public static void main(String[] args) {
        // 记录debug级别的信息
        logger.debug("This is debug message from Dao.");
        // 记录info级别的信息
        logger.info("This is info message from Dao.");
        // 记录error级别的信息
        logger.error("This is error message from Dao.");
    }
}

如果这个类作为基类，如J2EE中的BaseDao、BaseAction、BaseService等等，则我们可以将各层的日志信息分类输出到各个文件。

#省略根，只设置特定包的级别和目的地
log4j.logger.com.coderdream.log4j=debug,appender1
log4j.logger.com.coderdream.log4jDao=info,appender1,appender2

#输出到控制台
log4j.appender.appender1=org.apache.log4j.ConsoleAppender
#设置输出样式
log4j.appender.appender1.layout=org.apache.log4j.PatternLayout
#自定义样式
# %r 时间 0
# %t 方法名 main
# %p 优先级 DEBUG/INFO/ERROR
# %c 所属类的全名(包括包名)
# %l 发生的位置，在某个类的某行
# %m 输出代码中指定的讯息，如log(message)中的message
# %n 输出一个换行符号
log4j.appender.appender1.layout.ConversionPattern=[%d{yy/MM/dd HH:mm:ss:SSS}][%C-%M] %m%n

#输出到文件(这里默认为追加方式)
log4j.appender.appender2=org.apache.log4j.FileAppender
#设置文件输出路径
#【1】文本文件
log4j.appender.appender2.File=c:/Log4JDemo07_Dao.log
#设置文件输出样式
log4j.appender.appender2.layout=org.apache.log4j.PatternLayout
log4j.appender.appender2.layout.ConversionPattern=[%d{HH:mm:ss:SSS}][%C-%M] -%m%n

【示例8】 log4j.xml的配置方式

 1 <?xml version="1.0" encoding="UTF-8"?>
 2 <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
 3 
 4 <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
 5 
 6     <appender name="appender1"
 7         class="org.apache.log4j.RollingFileAppender">
 8         <param name="File" value="logfile08.html" />
 9         <param name="MaxFileSize" value="1MB" />
10         <param name="MaxBackupIndex" value="5" />
11         <layout class="org.apache.log4j.HTMLLayout">
12         </layout>
13     </appender>
14 
15     <root>
16         <level value="debug" />
17         <appender-ref ref="appender1" />
18     </root>
19 </log4j:configuration>

为了提高效率，我们可以在写日志前增加判断：

// 记录debug级别的信息
if (logger.isDebugEnabled()) {
    logger.debug("This is debug message from Dao.");
}

// 记录info级别的信息
if (logger.isInfoEnabled()) {
    logger.info("This is info message from Dao.");
}

// 记录error级别的信息
logger.error("This is error message from Dao.");