批量运行状态查询报空指针异常解决

服务器上发现批量运行状态查询有时会报系统未知错误，然后查询日志发现，batch端返回的rejcode=null，导致mweb无法识别错误类型。

但是为什么rejcode会等于null呢？

跟踪代码发现，batchtemplate里面有一个try catch，在catch里面会给rejcode重新赋值，所以验证try里面的代码

try {

            context.setData("_RequestJnlNo", context.getData("_MCHJnlNo"));

            context.setData("_ResponseRejCode", "000000");

            context.setData("_ResponseSystemId", "Batch");

            context.setData("_JnlState", JobState.Finish);

            

            super.execute(context);

        } catch (Throwable t) {

            context.setData("_JnlState", JobState.Failure);

            if (t instanceof PeException) {

                context.setData("_ResponseRejCode", ((PeException) t).getMessageKey());

                String msg = t.getMessage();

                try {

                    msg = context.getMessageSource().getMessage(((PeException) t).getMessageKey(), ((PeException) t).getArgs(), context.getLocale());

                } catch (Throwable t1) {

                    log.error("getmessage_failed", t1);

                }

                context.setData("_ResponseRejMsg", msg);

            } 

发现只有execute报空指针错误才能将rejcode赋值为null

跟踪发现super.execute执行的是JobStatusQryAction

在这个action里面有两个地方有可能会引起空指针，所以增加日志

        if (jobId != null && jobId.length() > 0) {

            log.info("jobId验证通过：" +jobId);

            Job job = this.getJobManager().getJob(jobId);

            log.info("job验证通过：" +job);

            if (job == null || !job.getRunKey().equals(jobKey)) {

                JobRuntimeData jrd = this.getJobManager().getJobRuntimeData(jobKey, jobId);

                jobLogList.add(jrd);

            } else {

                jobList.add(job);

            }

        } else {

            jobLogList = this.getJobManager().getJobRuntimeDataes(jobKey);

            log.info("jobLogList验证通过：" +jobLogList);

            jobList = this.getJobManager().getJobs();

            log.info("jobList验证通过：" +jobList);

            if (jobList != null){

                for (Iterator<Job> jt = jobList.iterator(); jt.hasNext();) {

                    Job jm = jt.next();

                    if (!jm.getRunKey().equals(jobKey)) {

                        jt.remove();

                    } else {

                        for (Iterator<JobRuntimeData> it = jobLogList.iterator(); it.hasNext();) {

                            JobRuntimeData tm = it.next();

                            if (tm.getId().equals(jm.getId())) {

                                it.remove();

                                break;

                            }

                        }

                    }

                }

            }

        }

        context.setData("JobList", jobList);

        context.setData("JobLogList", jobLogList);

    }

发现此处标红代码会引起空指针。为什么这里会空指针呢？

经排查发现是由于batch处理并发时，效率太低，引起死循环，导致此处remove为空

private Map<String, Job> jobMap = new HashMap<String, Job>();// 已初始化未完成的批量

private Map<String, Job> jobMap = new ConcurrentHashMap<String, Job>();// 已初始化未完成的批量

将此处HashMap改为ConcurrentHashMap

为什么此处不能用HashMap？因为HashMap线程不安全，在多线程环境下，使用Hashmap进行put操作会引起死循环，导致CPU利用率接近100%，所以在并发情况下不能使用HashMap。

以下来自网上摘抄：

效率低下的HashTable容器

     HashTable容器使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法时，其他线程访问HashTable的同步方法时，可能会进入阻塞或轮询状态。如线程1使用put进行添加元素，线程2不但不能使用put方法添加元素，并且也不能使用get方法来获取元素，所以竞争越激烈效率越低。

ConcurrentHashMap的锁分段技术

     HashTable容器在竞争激烈的并发环境下表现出效率低下的原因，是因为所有访问HashTable的线程都必须竞争同一把锁，那假如容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。

大致意思就是：ConcurrentHashMap将数据分段存储，并对每段数据都分配了一把锁，这样线程就有多条路，也不会在一条路上堵塞，引起崩溃。

另外在解决这个问题的时候发现MANIFEST.MF文件里面有一个很有意思的参数

CSII-AutoStart: true  //如果为ture则PE部署平台的普通用户可以在batch的包列表里面可见，默认为false 只有管理员sysadmin用户可见

CSII-StartLevel: 8      //包启动级别，级别低的启动优先。