博客园_Phinecos(洞庭散人)

深入剖析SolrCloud（一）

2012-02-10T08:36:00Z

SolrCloud是基于Solr和Zookeeper的分布式搜索方案，是正在开发中的Solr4.0的核心组件之一，它的主要思想是使用Zookeeper作为集群的配置信息中心。它有几个特色功能：1）集中式的配置信息 2）自动容错 3）近实时搜索 4）查询时自动负载均衡

基本可以用上面这幅图来概述，这是一个拥有4个Solr节点的集群，索引分布在两个Shard里面，每个Shard包含两个Solr节点，一个是Leader节点，一个是Replica节点，此外集群中有一个负责维护集群状态信息的Overseer节点，它是一个总控制器。集群的所有状态信息都放在Zookeeper集群中统一维护。从图中还可以看到，任何一个节点都可以接收索引更新的请求，然后再将这个请求转发到文档所应该属于的那个Shard的Leader节点，Leader节点更新结束完成，最后将版本号和文档转发给同属于一个Shard的replicas节点。

下面我们来看一个简单的SolrCloud集群的配置过程。

首先去https://builds.apache.org/job/Solr-trunk/lastSuccessfulBuild/artifact/artifacts/下载Solr4.0的源码和二进制包，注意Solr4.0现在还在开发中，因此这里是Nightly Build版本。

示例1，简单的包含2个Shard的集群

这个示例中，我们把一个collection的索引数据分布到两个shard上去，步骤如下：

为了弄2个solr服务器，我们拷贝一份example目录

cp -r example example2

然后启动第一个solr服务器，并初始化一个新的solr集群，

cd example
java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -DnumShards=2 -jar start.jar

-DzkRun参数是启动一个嵌入式的Zookeeper服务器，它会作为solr服务器的一部分，-Dbootstrap_confdir参数是上传本地的配置文件上传到zookeeper中去，作为整个集群共用的配置文件，-DnumShards指定了集群的逻辑分组数目。

然后启动第二个solr服务器，并将其引向集群所在位置

cd example2
java -Djetty.port=7574 -DzkHost=localhost:9983 -jar start.jar

-DzkHost=localhost:9983就是指明了Zookeeper集群所在位置

我们可以打开http://localhost:8983/solr/collection1/admin/zookeeper.jsp 或者http://localhost:8983/solr/#/cloud看看目前集群的状态，

现在，我们可以试试索引一些文档，

cd exampledocs
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar ipod_video.xml
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar monitor.xml
java -Durl=http://localhost:8983/solr/collection1/update -jar post.jar mem.xml

最后，来试试分布式搜索吧:

http://localhost:8983/solr/collection1/select?q

Zookeeper维护的集群状态数据是存放在solr/zoo_data目录下的。

现在我们来剖析下这样一个简单的集群构建的基本流程：

先从第一台solr服务器说起：

1) 它首先启动一个嵌入式的Zookeeper服务器，作为集群状态信息的管理者，

2）将自己这个节点注册到/node_states/目录下

3）同时将自己注册到/live_nodes/目录下

4）创建/overseer_elect/leader，为后续Overseer节点的选举做准备，新建一个Overseer，

5) 更新/clusterstate.json目录下json格式的集群状态信息

6) 本机从Zookeeper中更新集群状态信息，维持与Zookeeper上的集群信息一致

7）上传本地配置文件到Zookeeper中，供集群中其他solr节点使用

8) 启动本地的Solr服务器，

9) Solr启动完成后，Overseer会得知shard中有第一个节点进来，更新shard状态信息，并将本机所在节点设置为shard1的leader节点，并向整个集群发布最新的集群状态信息。

10）本机从Zookeeper中再次更新集群状态信息，第一台solr服务器启动完毕。

然后来看第二台solr服务器的启动过程：

1）本机连接到集群所在的Zookeeper，

2）将自己这个节点注册到/node_states/目录下

3）同时将自己注册到/live_nodes/目录下

4）本机从Zookeeper中更新集群状态信息，维持与Zookeeper上的集群信息一致

5）从集群中保存的配置文件加载Solr所需要的配置信息

6）启动本地solr服务器，

7） solr启动完成后，将本节点注册为集群中的shard，并将本机设置为shard2的Leader节点，

8）本机从Zookeeper中再次更新集群状态信息，第二台solr服务器启动完毕。

示例2，包含2个shard的集群，每个shard中有replica节点

如图所示，集群包含2个shard，每个shard中有两个solr节点，一个是leader，一个是replica节点，

cp -r example exampleB
cp -r example2 example2B
cd exampleB
java -Djetty.port=8900 -DzkHost=localhost:9983 -jar start.jar
cd example2B
java -Djetty.port=7500 -DzkHost=localhost:9983 -jar start.jar

我们可以打开http://localhost:8983/solr/collection1/admin/zookeeper.jsp 看看包含4个节点的集群的状态，

这个集群现在就具备容错性了，你可以试着干掉一个Solr服务器，然后再发送查询请求。背后的实质是集群的ov erseer会监测各个shard的leader节点，如果leader节点挂了，则会启动自动的容错机制，会从同一个shard中的其他replica节点集中重新选举出一个leader节点，甚至如果overseer节点自己也挂了，同样会自动在其他节点上启用新的overseer节点，这样就确保了集群的高可用性。

示例3 包含2个shard的集群，带shard备份和zookeeper集群机制

上一个示例中存在的问题是：尽管solr服务器可以容忍挂掉，但集群中只有一个zookeeper服务器来维护集群的状态信息，单点的存在即是不稳定的根源。如果这个zookeeper服务器挂了，那么分布式查询还是可以工作的，因为每个solr服务器都会在内存中维护最近一次由zookeeper维护的集群状态信息，但新的节点无法加入集群，集群的状态变化也不可知了。因此，为了解决这个问题，需要对Zookeeper服务器也设置一个集群，让其也具备高可用性和容错性。

有两种方式可选，一种是提供一个外部独立的Zookeeper集群，另一种是每个solr服务器都启动一个内嵌的Zookeeper服务器，再将这些Zookeeper服务器组成一个集群。我们这里用后一种做示例：

cd example
java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DnumShards=2 -jar start.jar
cd example2
java -Djetty.port=7574 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar
cd exampleB
java -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar
cd example2B
java -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -jar start.jar

我们可以打开http://localhost:8983/solr/collection1/admin/zookeeper.jsp 看看包含4个节点的集群的状态，可以发现其实和上一个没有任何区别。

后续的文章将从实现层面对SolrCloud这个分布式搜索解决方案进行进一步的深入剖析。

本文链接

技术宅---我的网上抢火车票攻略（终极秒杀版）

2012-01-10T12:38:00Z

前几天在我在博客上发了一篇《技术宅---我的网上抢火车票攻略》，短短4天内点击量达到8000多，可见火车票是近期最为火热的话题了。这几天又帮很多朋友代购火车票，不断总结经验教训，最后得到了一个完整的全自动刷票方案。

准备工作：

1)一键自动刷票软件Go-Home

下载地址：http://code.google.com/p/go-home/ ，这个软件有多牛逼，看看下面的项目简介就知道了。。。

2) Firefox浏览器或者Chrome浏览器

3) 12306自动登陆脚本

https://gist.github.com/raw/1570973/f200dd587f6d68ab81edf74436b1fb7d91c79973/12306AutoLogin.user.js

4) 12306自动查询脚本，https://gist.github.com/raw/1554666/dec45c925002ec23ccef9f5be14770572d27625c/12306.user.js

关于这两个脚本如何使用，请参见《技术宅---我的网上抢火车票攻略》的后半部分，

5) 招商银行信用卡或一卡通

6) UCWeb手机浏览器

下面我们开始从头至尾进行一次快速而完整的刷票之旅

第一步，使用一键刷票的Go-Home进行全自动刷票，它会自动识别验证码，自动登陆，自动查询车票信息，自动选择最优车次及席别，自动订票，如果你时间充裕，建议改成非自动模式，采用人工输入验证码相结合的方式进行刷票。这一步是至关重要的一步，同时也是最拼人品的一步，因为大家都知道，登陆和提交订单有多么困难。

第二步，如果你运气够好，在第一步中顺利地提交订单成功了，那么现在你要做的就是在45分钟内完成支付。这里我采用上面提到的12306自动登陆脚本，在Firefox和Chrome中打开登陆页面，通过Ajax请求的方式可以避免刷新验证码图片的问题，从而可以用同一个验证码无限次尝试登陆，直至登陆成功。

第三步，如果你人品继续足够好，侥幸在firefox或Chrome中登陆进系统了，那么恭喜你，赶紧进去最后一步支付吧。非IE用户无法使用网银，这个问题一直让人头痛，不过如果你有招商银行的信用卡或者一卡通，那么恭喜了，你可以无视这个问题了。当你选择使用招商银行进行支付时，非IE浏览器会打开手机支付的页面，输入你的卡号和手机号，它会将一个支付链接发到你的手机上，在手机上通过UCWeb浏览器打开这个链接，继续输入剩下的信息，就可以顺利完成支付了。

第四步，如果上帝继续眷顾你，让你顺利完成了支付，没有“支付超时“，没有“吞钱不吐票”，那么这下真的要恭喜你了，你成功了！！！

Ok,就总结到这里了，这应该算是目前最强大的终极火车票秒杀版本了，感谢互联网上众多无私奉献的人们，你们提供的工具，脚本，让我们能有机会买到回家的车票，却分文不取，这种精神让人敬佩，而我这几篇文章就是向诸位致敬！！！

本文链接

技术宅---我的网上抢火车票攻略

2012-01-06T13:49:00Z

写在前面

写这篇文章的起因是今天在12306上买火车票时，被这牛逼的网站给震撼到了，靠，牛叉得让人无语的用户体验啊。就讲讲我是如何利用一个小工具做辅助，幸运地抢到了回家的卧铺票的。希望能给有需要的兄弟们做个参考。

回顾下我今天网上购票的全过程，总结起来有四个难关，第一是登陆，第二是预定，第三是提交订单，第四是支付。本文的目的主要是为了在第一和第二关提供一些帮助。

准备工作：

1，firefox浏览器

2，油猴脚本扩展GreaseMonkey

（有园友反映这里看不懂啥意思，好吧，特别补充一段。GreaseMonkey是一个firefox扩展，当然，别再问我啥是扩展了，请自行google，简单说，就是装了这个扩展，就可以再它基础上跑一些js脚本，对页面做一些修改什么的。。。，）

先去这个页面下载扩展，https://addons.mozilla.org/zh-cn/firefox/addon/greasemonkey/，

下载到本地的是一个xpi文件，将其拖拽进firefox里面，就可以完成扩展的安装，重启firefox以后就生效，启用了GreaseMonkey

3，去这个页面安装12306 train ticket buyer脚本，http://userscripts.org/scripts/show/122334

（完成第二步以后，就可以直接在firefox里打开上述链接，页面上会有一个”Install”按钮，单击后就完成了脚本在油猴里的安装了）

下面我们就开始体验购票的整个流程吧。在firefox浏览器里安装好上面的油猴脚本后，首先打开登陆页面，http://www.12306.cn/mormhweb/kyfw/，这时你就会发现页面上出现了下面这个设置区域

如果你没看到，请记得去确认下GreaseMonkey扩展是否已经启用，就在地址栏最右边那个小猴子，记得点亮它，嘿嘿。

Ok,再来介绍下这个脚本的功能，它对我们闯第一，二关有一定的辅助功效，功能1：登录助手（自动填充用户名密码，验证码输入框自动获得焦点，无需碰鼠标即可输入验证码回车重复登录）；功能2：自动查询车票（根据用户事先配置的始发到站信息，自动查询）

先说说第一关---登陆，每天整点放票的时候，想登陆进去真是难如登天，每次都会弹出下面这个让人泪流满面的窗口，尼玛连个登陆进去的机会都不给啊。。。

更可恶的是，如果你用IE浏览器的话，密码会清空，鼠标焦点也没有选中在任何一个输入框，你不得不鼠标移到密码框，重输密码，再验证码，再鼠标单击“登录“，如果你用的是firefox呢，情况稍微好点，起码密码可以帮你保存，可还是上面的鼠标动作免不了。

大家懂的，这时候，速度就是一切，差之毫厘，失之千里，省下那么一点点鼠标操作的时间，你就比别人多了几次登录的机会啊。

这就是上面那个油猴脚本能帮到你的地方了，安装了以后，你会发现，登录时，你只需要使用键盘进行操作，就两个动作，输入验证码，回车，如果失败，再次回车干掉弹出框，此时鼠标焦点依旧在验证码那，继续输入验证码，回车，。。。。只要你键盘操作够快，此时的你绝对是正常登录操作的好几倍啊，有么有？哈哈

Ok,千辛万苦终于爬进系统里头来了，下一关—就是预定，这个脚本在这里还是继续可以帮到你一点点的。

如果不用上面这个脚本的话，正常的操作流程是自己填写出发站点和到达站点，出发日期，点击“重新查询“按钮，完了你发现没票，囧了，又重新填一遍信息，再点，还是没票，又来一遍？

这时候上面的油猴脚本就可以帮我们做这种无聊的重填信息动作了，上面我们不是设置了出发站点和到达站点，出发日期嘛，这些信息就是脚本用来在车票查询的时候自动重填的，

你现在只管不断地点“重新查询“按钮，期待着宝贵的车票出现，然后你懂的，剩下的预定是否成功，订单是否提交成功，支付是否能完成，那就只有老天爷知道了。。，

当然，登陆不进，进去了又被踢下线，502 Bad Gateway，这些问题就无语了，没办法，只有不断的重试，重试，再重试，关键时刻还得拼人品，拼运气的。

此外，网上有文章介绍如何用firebug修改html页面上的参数值，然后在提交页面来快速下订单的教程，见《网友提供Firefox+扩展 15秒网上快速预定火车票教程》，但我也试了，基本用处不大，能否提交订单成功，真的是只有上帝才知道，我基本都卡在这里，眼看着有票，可订单死活提交不上去。。。

但起码这个脚本可以让我们节省出不少的时间，在这全民抢票的时代，时间就是机会，时间就是金钱啊，心动了么？赶紧照着我这个教程试试吧。

最后，再推荐一个Chromium下的脚本，我使用的是Chromium 16

1,首先在Chromium中打开下述链接，安装12306 auto query脚本。

https://gist.github.com/raw/1554666/dec45c925002ec23ccef9f5be14770572d27625c/12306.user.js

2，登陆到12306，选择“车票预订”，填写好信息后进行一次查询后，就会看到下面的画面。

程序是会自动查询，当有票时会会高亮有票的车次。在查询期间你可以做其他事情，但要保持标签页开启（是否是当前标签页无所谓）。注意：1) 只在 Chromium 上调试过。2) 不支持自动订票,有票后请手工操作。

这个脚本最有用的地方在哪里呢？有时候你查询车票的时候，会显示一张票都没有了，但是请不要绝望，因为还是有一点点希望的。因为有人会退票，或者是有些人会因为支付失败，超时等原因，系统会把票重新收回，这时候这个脚本就给力了，你可以比别人快一步看到这些珍稀资源，当你看到那红色高亮的“一条杠”的时候，该怎么做，你懂的。。。。

另外，再附带吐槽一下，这系统里的硬座票和无座票是统一归在“硬座票”里的，因此，当你看到页面上显示硬座还有票的时候，请别高兴得太早，很可能你支付完成后就发现，你拿到手的居然是“无座票”，这坑爹的玩意。。。，

还有就是，一定要同时使用多个浏览器，甭管什么IE啊，Firefox啊，Chrome啊,总之能整上的都给它整上。。。在每个浏览器上都去登陆，上去了之后，就是一个字---刷，甚至你还可以制定相应的策略，分车次，分站点来刷，总而言之，就是拼命刷之,别让12306后台系统那帮龟孙子闲着。。。

最后，可能有人会问那最后一步支付咋办呢？难不成要重新换IE登陆上了，在限时的45分钟内去用网银来完成支付么？很可能是一去不复返了。。。其实，在firefox和chrome下也是可以完成支付的，如果你有招商银行，那么支付时就可以使用手机支付来搞定的。只要是非IE浏览器登录时，默认会定位到手机支付页面

哈哈，反正我今天是坚持不懈的斗争，终于抢到了一张回家的卧铺票，一点小经验，不敢独享，拿出来给大家分享，咱技术宅买个票就得像打仗一样，仔细研究对手，做好一切能做的准备，打持久战，不是么？

本文链接

一次针对批量查询处理的优化

2011-12-29T15:10:00Z

客户调用批量查询接口对Solr核进行查询时觉得查询响应时间有些慢，接口的内部实现目前是顺序执行每个查询，再把结果汇总起来返回给调用方。因此，考虑引入线程池对查询接口的内部实现进行重构优化。

先声明一个大小可随之增长的线程池，

private ExecutorService executor = Executors.newCachedThreadPool();//查询请求处理线程池

然后是主线程方法的代码：

public List<Map<String, String>> queryEntityList(String entityCode, List<Long> idList) throws ServiceException {

        List<Map<String, String>> finalResult = null;
        if (idList == null || idList.size() == 0 || StringUtil.isBlank(entityCode)) {//参数合法性校验
            return finalResult;
        }
        finalResult = new ArrayList<Map<String, String>>();

        List<Future<Map<String, String>>> futureList = new ArrayList<Future<Map<String, String>>>();
        int threadNum = idList.size();//查询子线程数目
        for (int i = 0; i < threadNum; i++) {
            Long itemId = idList.get(i);
            Future<Map<String, String>> future = executor.submit(new QueryCallable (entityCode, itemId));
            futureList.add(future);
        }
        for(Future<Map<String, String>> future : futureList) {
            Map<String, String> threadResult = null;
            try {
                threadResult = future.get();
            } catch (Exception e) {
                threadResult = null;
            }
            if (null != threadResult && threadResult.size() > 0) {//结果集不为空
                finalResult.add(threadResult);
            }
        }
        return finalResult;
    }

最后是具体负责处理每个查询请求的Callable

public class QueryCallable implements Callable<Map<String, String>> {
        private String entityCode = "";
        private Long itemId = 0L;

        public GetEntityListCallable(String entityCode, Long itemId) {
            this. entityCode = entityCode;
            this.itemId = itemId;
        }
        public Map<String, String> call() throws Exception {
            Map<String, String> entityMap = null;
            try {
                entityMap = QueryServiceImpl.this.getEntity(entityCode, itemId);//先去hbase查基本信息

            } catch (Exception e) {
                entityMap = null;
            }
            return entityMap;
        }
    }

通过线程池的使用，可以减少创建，销毁进程所带来的系统开销，而且线程池中的工作线程可以重复使用，极大地利用现有系统资源，增加了系统吞吐量。

另外，今天也尝试了另一种合并Solr索引的方法，直接通过底层的Lucene的API进行，而不是提交Http请求，具体方法如下:

java -cp lucene-core-3.4.0.jar:lucene-misc-3.4.0.jar org/apache/lucene/misc/IndexMergeTool ./newindex ./app1/solr/data/index ./app2/solr/data/index

本文链接

每日学习笔记(23)

2011-11-17T04:17:00Z

1,从前端传过来的参数是"\u9676\u9676\u6D4B\u8BD5\u8D26\u53F701"这样的unicode编码，需要将其转换为中文字符串，发现java.util.Properties类中有一个loadConvert函数可以完成这件事，直接copy过来使用。

public static String loadConvert(char[] in, int off, int len, char[] convtBuf) {
        if (convtBuf.length < len) {
            int newLen = len * 2;
            if (newLen < 0) {
                newLen = Integer.MAX_VALUE;
            }
            convtBuf = new char[newLen];
        }
        char aChar;
        char[] out = convtBuf;
        int outLen = 0;
        int end = off + len;

        while (off < end) {
            aChar = in[off++];
            if (aChar == '\\') {
                aChar = in[off++];
                if (aChar == 'u') {
                    // Read the xxxx
                    int value = 0;
                    for (int i = 0; i < 4; i++) {
                        aChar = in[off++];
                        switch (aChar) {
                        case '0':
                        case '1':
                        case '2':
                        case '3':
                        case '4':
                        case '5':
                        case '6':
                        case '7':
                        case '8':
                        case '9':
                            value = (value << 4) + aChar - '0';
                            break;
                        case 'a':
                        case 'b':
                        case 'c':
                        case 'd':
                        case 'e':
                        case 'f':
                            value = (value << 4) + 10 + aChar - 'a';
                            break;
                        case 'A':
                        case 'B':
                        case 'C':
                        case 'D':
                        case 'E':
                        case 'F':
                            value = (value << 4) + 10 + aChar - 'A';
                            break;
                        default:
                            throw new IllegalArgumentException(
                                    "Malformed \\uxxxx encoding.");
                        }
                    }
                    out[outLen++] = (char) value;
                } else {
                    if (aChar == 't')
                        aChar = '\t';
                    else if (aChar == 'r')
                        aChar = '\r';
                    else if (aChar == 'n')
                        aChar = '\n';
                    else if (aChar == 'f')
                        aChar = '\f';
                    out[outLen++] = aChar;
                }
            } else {
                out[outLen++] = (char) aChar;
            }
        }
        return new String(out, 0, outLen);

}

本文链接

一次内存泄露问题的排查

2011-11-13T17:11:00Z

系统对外提供的Solr查询接口，在来自外部调用的压力加大之后，就会出现solr查询报Read Timed Out的异常，从表面现象上看是此时solr核压力过大，无法响应过多的查询请求。

但实际上此时并发查询压力并不是很大，那么为何solr核会无法及时响应查询请求呢？首先用top查看了下load average，也是很低，也佐证了系统本身压力并不大。

然后，用jstack –l <pid> 查看那些cpu使用率过高的线程，发现全都是GC线程，说明GC过于频繁，而且耗时过长，导致应用线程被挂起，无法响应客户端发来的请求，这种情况就应该是有存在内存泄露的问题咯。

于是，就用jmap将进程的堆转储文件dump出来到heap.bin文件中

JMap -dump:format=b,file=/tmp/heap.bin <pid>

然后用Eclipse Memory Analyzer（MAT）打开堆转储文件进行分析

通常我们都会采用下面的“三步曲”来分析内存泄露问题：

首先，对问题发生时刻的系统内存状态获取一个整体印象。

第二步，找到最有可能导致内存泄露的元凶，通常也就是消耗内存最多的对象

接下来，进一步去查看这个内存消耗大户的具体情况，看看是否有什么异常的行为。

下面来展示如何采用“三步曲”来查看生产的分析报告。

查看报告之一：内存消耗的整体状况

如上图所示，在报告上最醒目的就是一张简洁明了的饼图，从图上我们可以清晰地看到一个可疑对象消耗了系统75% 的内存。

现在，让我们开始真正的寻找内存泄露之旅，点击“Leak Suspects”链接，可以看到如下图所示对可疑对象的详细分析报告。

我们查看下从 GC 根元素到内存消耗聚集点的最短路径

我们可以很清楚的看到整个引用链，内存聚集点是一个拥有大量对象的列表，如果你对代码比较熟悉的话，相信这些信息应该能给你提供一些找到内存泄露的思路了。

接下来，我们再继续看看，这个对象集合里到底存放了什么，为什么会消耗掉如此多的内存。

在这张图上，我们可以清楚的看到，这个列表中保存了大量 HashMap 对象的引用，就是它导致的内存泄露。

至此，我们已经拥有了足够的信息去寻找泄露点，回到代码中就发现，List没有clear或者设置为null，导致其包含的强引用的各个HashMap没有得到释放。至此，问题得到解决。

下面我们来继续深入研究java的内存泄露问题。Java的一个重要优点就是通过垃圾收集器(Garbage Collection，GC)自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC或JVM的问题。其实，这种想法是不正确的，因为Java也存在内存泄露，但它的表现与C++不同。

随着越来越多的服务器程序采用Java技术，例如JSP，Servlet， EJB等，服务器程序往往长期运行。另外，在很多嵌入式系统中，内存的总量非常有限。内存泄露问题也就变得十分关键，即使每次运行少量泄漏，长期运行之后，系统也是面临崩溃的危险。

为了判断Java中是否有内存泄露，我们首先必须了解Java是如何管理内存的。Java的内存管理就是对象的分配和释放问题。在Java中，程序员需要通过关键字new为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由GC决定和执行的。在Java中，内存的分配是由程序完成的，而内存的释放是有GC完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是Java程序运行速度较慢的原因之一。因为，GC为了能够正确释放对象，GC必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC都需要进行监控。

监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。

为了更好理解GC的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用者指向被引对象。另外，每个线程对象可以作为一个图的起始顶点，例如大多程序从main进程开始执行，那么该图就是以main进程顶点开始的一棵根树。在这个有向图中，根顶点可达的对象都是有效对象，GC将不回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。

以下，我们举一个例子说明如何用有向图表示内存管理。对于程序的每一个时刻，我们都有一个有向图表示JVM的内存分配情况。以下右图，就是左边程序运行到第6行的示意图。

Java使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达的，那么GC也是可以回收它们的。这种方式的优点是管理内存的精度很高，但是效率较低。另外一种常用的内存管理技术是使用计数器，例如COM模型采用计数器方式管理构件，它与有向图相比，精度行低(很难处理循环引用的问题)，但执行效率很高。

下面，我们就可以描述什么是内存泄漏。在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。

在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java中，这些不可达的对象都由GC负责回收，因此程序员不需要考虑这部分的内存泄露。

通过分析，我们得知，对于C++，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。通过这种方式，Java提高了编程的效率。

因此，通过以上分析，我们知道在Java中也有内存泄漏，但范围比C++要小一些。因为Java从语言上保证，任何对象都是可达的，所有的不可达对象都由GC管理。

对于程序员来说，GC基本是透明的，不可见的。虽然，我们只有几个函数可以访问GC，例如运行GC的函数System.gc()，但是根据Java语言规范定义，该函数不保证JVM的垃圾收集器一定会执行。因为，不同的JVM实现者可能使用不同的算法管理GC。通常，GC的线程的优先级别较低。JVM调用GC的策略也有很多种，有的是内存使用到达一定程度时，GC才开始工作，也有定时执行的，有的是平缓执行GC，有的是中断式执行GC。但通常来说，我们不需要关心这些。除非在一些特定的场合，GC的执行影响应用程序的性能，例如对于基于Web的实时系统，如网络游戏等，用户不希望GC突然中断应用程序执行而进行垃圾回收，那么我们需要调整GC的参数，让GC能够通过平缓的方式释放内存，例如将垃圾回收分解为一系列的小步骤执行，Sun提供的HotSpot JVM就支持这一特性。

下面给出了一个简单的内存泄露的例子。在这个例子中，我们循环申请Object对象，并将所申请的对象放入一个Vector中，如果我们仅仅释放引用本身，那么Vector仍然引用该对象，所以这个对象对GC来说是不可回收的。因此，如果对象加入到Vector后，还必须从Vector中删除，最简单的方法就是将Vector对象设置为null。

Vector v=new Vector(10);

for (int i=1;i<100; i++)
{
    Object o=new Object();
    v.add(o);
    o=null;
}

本文链接

每日学习笔记(22)

2011-10-18T03:03:00Z

1，使用JMX监控Solr,

首先在solrconfig.xml中确保没有注释掉下述配置项，以便启用JMX。

<jmx />

然后在启动时加入一些启动参数来支持远程连接：

java -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=3000 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar start.jar

Jdk提供了一个图形化的工具JConsole

[JDK_HOME]/bin/jconsole

连接jmx服务器

基本监控信息：

本文链接

每日学习笔记(21)

2011-10-12T11:50:00Z

1，今天收到报警信息，说应用所在机器的硬盘空间不足了，上去一看，居然发现国庆这几天的日志信息累计达到了260多G，可看了下应用下的日志，实际只有几十M而已，进一步check后发现是调用的第三方应用在另一个日志路径下打出大量的Debug信息，回查代码后才明白是Logback和Log4J的冲突问题，于是写了一个类在应用启动时将Log4J的级别调高至ERROR级别，代码如下：

public class Log4jInit {

   privatestatic String logFilePath;
    private final static String DEFAULT_LOG4J_FILE_NAME = "log4j.xml";
    private org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(getClass());

    private void configureLog4j() throws javax.xml.parsers.FactoryConfigurationError {

        System.setProperty( "org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog" );
        Properties p = new Properties();
        p.put("log4j.logger.httpclient.wire", Level.ERROR);
        p.put("log4j.logger.org.apache.commons.httpclient", Level.ERROR);

        Logger root = Logger.getRootLogger();
        boolean rootIsConfigured = root.getAllAppenders().
        hasMoreElements();
        if(root != null) {
            root.setLevel(Level.ERROR);
        }

        log.error("turn off log4j");
    }

    public static String getLogFilePath() {
        return logFilePath;
    }

    public static void setLogFilePath(String logFilePath) {
        Log4jInit.logFilePath = logFilePath;
    }
}

本文链接

每日学习笔记(20)

2011-09-28T06:54:00Z

1, Solr合并索引数据有两种方法，第一种是1.4版本中引入的，通过CoreAdminHandler来实现，示例如下：

http://localhost:8983/solr/admin/cores?action=mergeindexes&core=core0&indexDir=/opt/solr/core1/data/index&indexDir=/opt/solr/core2/data/index

上述命令会将core1和core2的索引合并到core0中去，这里最值得注意的一点是：一旦合并完成，必须在core0上调用commit操作，否则索引数据的变化对于searchers来说是暂时不可见的，只有等到下次core0重新装载起来时才可见。

实现代码如下：

/**

     * 合并索引数据
     * @param otherIndexPathList 其他待合并的索引数据路径
     * @param coreName 合并的目标solr核名称
     *
     */    private void mergeIndexData(List<String> otherIndexPathList, String coreName) {
        if (null != otherIndexPathList && otherIndexPathList.size() > 0) {
            HttpClient client = new HttpClient();
            client.setConnectionTimeout(20000);
            client.setTimeout(20000);
            client.setHttpConnectionFactoryTimeout(20000);

            StringBuffer sb = new StringBuffer();
            for (int i = 0; i < otherIndexPathList.size(); ++i) {
                sb.append("&indexDir=" + otherIndexPathList.get(i) + "/data/index");
            }
            String mergeIndexCMD = "http://" + Constants.LOCAL_ADDRESS + ":" + this.port  + "/admin/cores?action=mergeindexes&core="+ coreName;
            if (sb.length() > 0) {
                mergeIndexCMD += sb.toString();
            }
            HttpMethod method = new GetMethod(mergeIndexCMD);
            method.getParams().setContentCharset("GBK");
            method.getParams().setHttpElementCharset("GBK");
            method.getParams().setCredentialCharset("GBK");

            // execute the method.
            try {
                if (client.executeMethod(method) == 200) {
                    String response = method.getResponseBodyAsString();
                    if (logger.isInfoEnabled()) {
                        logger.info("merge result" + response);
                    }
                }
            } catch (Exception e) {
                logger.error("合并其他索引数据失败 " + coreName + "，索引目录: " + otherIndexPathList, e);
            }

            //commit操作让合并后的索引对搜索生效
            StreamingUpdateSolrServer httpSolrServer = null;
            httpSolrServer = getSolrServer(Constants.LOCAL_ADDRESS, this.port, coreName);
            try {
                httpSolrServer.commit();
            } catch (Exception e) {
            }
        }
    }

第二种方法是Solr3.3中引入的，也是通过CoreAdminHandler来实现，示例如下：

http://localhost:8983/solr/admin/cores?action=mergeindexes&core=core0&srcCore=core1&srcCore=core2

同第一种方法一样，一旦合并完成，必须在core0上调用commit操作，否则索引数据的变化对于searchers来说是暂时不可见的，只有等到下次core0重新装载起来时才可见。

使用”srcCore”和”indexDir”这两种方法的区别：

1) 使用”indexDir”参数，你可以合并不是与Solr核相关联的索引数据，比如通过Lucene直接创建的索引

2) 使用”indexDir”参数，你必须注意索引数据不是直接写入的，这就意味着如果它是一个solr核的索引，必须要关闭IndexWriter，这样才能触发一个commit命令。

3) “indexDir”必须指向solr核所在的主机上的磁盘路径，这就限制比较多了，而相反，你可以只给srcCore一个solr核的名称，而不关心它的实际索引路径在哪。

4) 使用”srcCore”，你必须确保即使源索引数据同时存在写操作的时候，合并后的索引页不会损坏。

2, solr索引合并的时候，底层其实调用的还是Lucene，因此你schema.xml中配置的uniqueKeys它并不知道，因此当你对两个包含相同文档（由uniqueKey确定）的索引进行合并时，你会得到双倍的文档数，solr这个地方应该改下，毕竟你不是简单的Lucene包装嘛。。。

本文链接

每日学习笔记(19)

2011-08-23T12:30:00Z

今天的工作需求如下：有一个生产者负责生成源数据，将数据插入到多个工作队列中，每个工作队列由一个线程池进行处理，即每个线程池中可以启动多个线程对与其对应的工作队列中的元素取出来进行处理。

我将业务需求抽象为一个“单生产者—多消费者集群”模型，写了一个模拟代码进行测试，明天打算把模型再套回到业务中去。

import java.text.DateFormat;
import java.util.Collection;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;
import java.util.Map.Entry;
import java.util.Random;
import java.util.Set;
import java.util.concurrent.ArrayBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

/**
* 测试工作队列和线程池
* @author fayin.dyk
*
*/
/**
* 测试流程: 0,预先创建n个工作队列
*             1,一个生产者线程不断生产QueueElement，将其放置到n个工作队列中
*             2,每个工作队列有一个对应的线程池，其中的工作线程从队列中依次取
*             QueueElement，并进行相应的处理
*/

public class TestWorkQueue {

    private static Map<String, WorkQueue> workQueueList = null;//n个商品库工作队列
    private static int QUEUE_NUM = 10;
    static {
        initWorkQueue();
    }

    /**
     * 初始化n个工作队列
     */
    private static void initWorkQueue() {
        //创建同样数量的工作队列
        workQueueList = new HashMap<String, WorkQueue>(QUEUE_NUM);//队列名称与对应的工作队列
        for (int i = 0; i < QUEUE_NUM; ++i) {
            String entityName = "auction" + i;
            WorkQueue workQueue = new WorkQueue();
            workQueueList.put(entityName, workQueue);
        }
    }
    /**
     * 单个的生产者线程,不断生产QueueElement，放置到n个工作队列中
     * @author fayin.dyk
     *
     */
    private static class ProducerThread implements Runnable {
        private boolean isNeedToStop = false;

        /**
         * 生成行键值
         * @param itemId 商品id
         * @return
         */
        private String generateRowKey(String itemId) {
            String result = "";
            DateFormat format = new java.text.SimpleDateFormat("yyyyMMddHHmmss");
            Date curDate = new Date();
            String curDateStr = format.format(curDate);
            result = curDateStr + "_" + itemId;
            return result;
        }

        private QueueElement generateQueueElement() {//随机生产element
            String msgType = ItemNotifyConstants.NM_item_add;//消息类型
            //商品id
            Random rnd = new Random();
            String rndItemId = String.valueOf(rnd.nextInt(10000));
            String rowKey = generateRowKey(rndItemId);
            String location = "hz";
            String title = "auction_" + rndItemId;
            QueueElement element = new QueueElement(msgType,rowKey, rndItemId,  rndItemId, location, title, rndItemId);
            return element;
        }
        /**
         * 分发到各个工作队列中
         */
        private void deployWorkElement(QueueElement element) {
            Collection<WorkQueue> queueSet = workQueueList.values();
            for (WorkQueue workQueue : queueSet) {
                workQueue.enQueue(element);
            }
        }
        public void run() {
            while (!isNeedToStop) {
                //生产QueueElement,放置到n个工作队列中
                QueueElement element = generateQueueElement();
                deployWorkElement(element);
                System.out.println("生产者生产商品id : " + element.getItemID() + "\n");
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                }
            }
        }
    }

    /**
     * 消费者，每个消费者是与一个队列对应的线程池，其中的线程从此队列中取element，进行相应处理
     * @author fayin.dyk
     *
     */
    private static class Consumer {
        private final static int CORE_THREAD_NUM = 20;
        private final static int MAX_THREAD_NUM = 21;
        private final static int CAPACITY = 1000;
        public String queueName = "";//当前队列名称
        public WorkQueue workQueue = null;//与其对应的工作队列

        public Consumer(WorkQueue workQueue, String queueName) {
            this.workQueue = workQueue;
            this.queueName = queueName;
        }

        ThreadPoolExecutor indexerThreadPool = new ThreadPoolExecutor(
                CORE_THREAD_NUM, MAX_THREAD_NUM, 10, TimeUnit.SECONDS,
                new ArrayBlockingQueue<Runnable>(CAPACITY));//处理对应队列的消费者线程

        public void process() {
            indexerThreadPool.execute(new IndexerJobThread(workQueue, queueName));
            indexerThreadPool.execute(new IndexerJobThread(workQueue, queueName));
        }

        private static class IndexerJobThread implements Runnable {
            public String queueName = "";//当前队列名称
            public WorkQueue workQueue = null;
            public IndexerJobThread(WorkQueue workQueue, String queueName) {
                this.workQueue = workQueue;
                this.queueName = queueName;
            }
            public void run() {
                System.out.println("消费者,当前队列  " + queueName + "队列大小" + workQueue.queueSize() +  " 消费者线程id: " + Thread.currentThread().getId() + "\n");

                while (true) {
                    if (!workQueue.isEmpty()) {
                        QueueElement element = workQueue.deQueue();
                        if (element != null) {
                            System.out.println("消费者,当前队列  " + queueName + " 商品id: " + element.getItemID() + " " + "消费者线程id: " + Thread.currentThread().getId() + "\n");
                        }
                    }
                    try {
                        Thread.sleep(100);
                    } catch (InterruptedException e) {
                    }
                }
            }
        }

    }
    /**
     * 为各个工作队列初始化对应的消费者(每个消费者包含一个线程池来进行处理)
     */
    private static void initConsumers() {
        Set<Entry<String, WorkQueue>> queueSet = workQueueList.entrySet();
        for (Entry<String, WorkQueue> workQueueEntry : queueSet) {
            String queueName = workQueueEntry.getKey();
            WorkQueue workQueue = workQueueEntry.getValue();
            System.out.print("queueName: " + queueName + "workQueue:" + workQueue + "\n");
            Consumer consumer = new Consumer(workQueue, queueName);
            consumer.process();
        }
    }
    public static void main(String[] args) {
        //生产者启动
        Thread producer = new Thread(new ProducerThread());
        producer.start();
        //启动消费者群
        initConsumers();
        try {
            Thread.sleep(100000);
        } catch (InterruptedException e) {
        }
    }

}

本文链接