写这篇文章的原因是昨天在工作期间完成业务要求的时候，根据组长的要求写了自己的代码，结果在之后组长review的时候，发现了很多不足的地方，所以写这篇博客进行记录。
话不多说，先上原始代码。
public class DocValuesWarmUpListener extends AbstractSolrEventListener{
private static final Logger logger = LoggerFactory.getLogger(DocValuesWarmUpListener.class);
private List<String> fields;
public DocValuesWarmUpListener(SolrCore core) {
super(core);
}
@Override
public void init(NamedList args) {
super.init(args);
fields = new ArrayList<>();
NamedList o;
if(args != null) {
o = (NamedList) args.get("fields");
if(o!=null && o instanceof NamedList) {
for (int i = 0; i < o.size(); i++) {
fields.add((String) o.getVal(i));
}
}
}
}
@Override
public void newSearcher(SolrIndexSearcher newSearcher, SolrIndexSearcher currentSearcher) {
long start = System.currentTimeMillis();
ExecutorService executorService = Executors.newFixedThreadPool(fields.size());
try {
//排序所需要用到的字段,用一个线程池多线程预热
for(int i=0;i<fields.size();i++) {
executorService.execute(new WarmUpDocValueThread(fields.get(i),newSearcher));
}
} catch (Exception e) {
throw new IllegalStateException(e);
}finally {
logger.info("warming up consumes ["+(System.currentTimeMillis()-start)+"] Millis");
}
}
class WarmUpDocValueThread implements Runnable{
private String field;
private SolrIndexSearcher newSearcher;
public WarmUpDocValueThread(String field,SolrIndexSearcher newSearcher) {
this.field = field;
this.newSearcher = newSearcher;
}
@Override
public void run() {
try {
DocValues.getSorted(this.newSearcher.getLeafReader(), this.field);
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
这里先大概解释一下这段代码的业务需求。
由于在业务方进行一个查询工作的时候，发现有一段查询语句的时间抖动非常大，最长耗时可能到6000ms，快的时候在400ms左右。所以组长分析是该查询语句涉及到排序，而solr周期性的softCommit之后，会需要对整个docValue进行重新merge，所以会造成周期性的抖动。所以需要在softComiit之后先进行对docValue的预热。
确定逻辑后，让我上手完成这个逻辑。整个代码逻辑也不复杂，就是写一个eventListener，在init()方法中初始化solrconfig.xml的配置，在newSearcher()方法中对docValue进行预热。
所以写了以上这一版本，在组长review的时候，发现了很多不足，现在记录一下，也是以后尽量避免。
1: 在多线程并发情况下，没有设置主线程的堵塞，及在多线程同时对docValue进行预热的情况下，主线程并不等待预热完成而直接继续执行。针对这个问题，在修改的第一版本中，在多线程开启后，加入thread.join()，完成主线程的等待，在组长的建议下修改成了countDownLatch。这里顺便写一下countDownLatch和join用法的区别。
本质上countDownLatch和join都实现同一个目的，即多线程并发编程时，当各别线程需要等待特定的其他线程任务执行完成后再执行时，用到以上两个方法。具体使用方法这里先不赘述了，主要讲讲不同的使用场景。
在使用join时，阻塞线程必须等待其他线程任务完全结束后才能继续执行，而使用countDownLatch时，可以任意指定其他线程的执行程度。
举个例子，此时有A，B，C三个线程进行任务执行，假设三个线程任务均为执行100的计数且A线程必须等到B，C计数完成再执行，此时用join或者countDownLatch都能完成任务要求。但是如果任务改成，A线程必须等到B，C都计数到50时，再开始执行，此时join不能完成这个要求，但是用countDownLatch时可以实现，即先
CountDownLatch cdl = new CountDownLatch(2) //A线程 cld.await() //B线程完成50次计数时 cld.countDown() //C线程完成50次计数时 cld.countDown()
以上代码即可实现要求,以上仅为伪代码，实际编程时注意要把cld.countDown()写在finally里面，避免有一线程崩溃而造成死锁。
第二个不足在于对代码的可配置化程度上，第一版的代码将代码参数写的过于生硬，很难被以后的代码复用，经过组长提示，对AbstractSolrEventListener源码的阅读发现有一个init方法，可以实现对schema.xml文件的配置参数的读取，果断覆写这个方法，将所需要预热的field配置在xml文件中。
本文主要记录一下这次的经验。