一、solrj新建文档索引官方代码。新建一个request，为这个request添加文件，行为，参数，然后提交给solr服务器。
ContentStreamUpdateRequest up = new ContentStreamUpdateRequest("/update/extract");
up.addFile(new File("mailing_lists.pdf"));
up.setParam("literal.id", "mailing_lists.pdf");
up.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);
result = server.request(up);
二、最初采用单线程新建索引方式，发现新建60个文档需要30分钟，900个文档目测要一天（导致这个问题的原因后面再说）。所以编写了多线程建立索引的方式。结果时间确实大大减少了，900个文档需要40分钟。但是查阅官方资料发现，solr建索引的速度在每秒10-150个文档之间。所以这个速度还是太低。查看日志发现为文档建索引的时间是越来越长的。
三、根据日志估计是缓存的问题，修改solr.config文件中的缓存设置。新建900个文档的索引时间仅仅由40分钟提高到了30多分钟。所以不是缓存的问题。
四、继续查看日志，发现每次提交都导致openSearcher，和registered new search。以为是每次为文件建索引都要提交导致的。所以修改官方提供的代码。不设置Action。并且到最后才提交文档。细心的读者看到以下代码可能就会发现本菜鸟错在哪里了。代码如下：
ContentStreamUpdateRequest up = new ContentStreamUpdateRequest("/update/extract");
for(File file:files){
up.addFile(new File("mailing_lists.pdf"));
up.setParam("literal.id", "mailing_lists.pdf");
//up.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);//注释这行代码。
server.request(up);//
}
server.commit();
五、发现修改新建索引速度还是不提高。于是各种折腾，看源码，重写源码。各种尝试4天左右。发现request的contentStream数量不对。调用up.getContentStreams().size()发现contentStream是递增的。好吧，终于找到原因了。我把ContentStreamUpdateRequest up声明在循环体外面，导致addfile每次往up里面添加file。最终文件越来越多，时间自然也就越来越慢了。（这个错误真的太低级了，之前看到说solrserver是重量级的，想当然以为up也是重量级的。放在循环体外可以优化性能）。
六、虽然犯了这个低级错误，但是最终还是了解了很多solr缓存，以及不用单个文件每次都调用commit的方法。还是不错了。最终代码如下：
ContentStreamUpdateRequest up;
for(File file:files){
up=new ContentStreamUpdateRequest("/update/extract");
up.addFile(new File("mailing_lists.pdf"));
up.setParam("literal.id", "mailing_lists.pdf");
//up.setAction(AbstractUpdateRequest.ACTION.COMMIT, true, true);//注释这行代码。
server.request(up);//这里的server使用的是EmbeddedSolrServer。
}
server.commit();