本发明涉及互联网技术领域，特别涉及一种基于JAVA多线程技术解决物联云端服务雪崩效应的方法。

背景技术：

目前，物联云系统已经作为普遍的智能电视平台出现在我们面前，而细致分析物联云系统我们可以发现，当使用物联云用户到达峰值时(即用户请求数到达一定阈值)，将会导致后续用户请求进入排队等待或者请求直接被拒绝的情况，这些请求排队到一定程度后，就可能直接导致了物联云系统雪崩效应的产生。国内现有的解决方案有：设置负载均衡权重调度规则，支持对云端服务优先级的升降进行调控。权重调度规则是指单位时间内失败次数超过阈值的微服务优先级降到最低，然后再按照最佳响应时间规则选择其他优先级更高的微服务；单位时间可以设置，默认是5分钟，阈值默认是20次，尽可能将请求分配至另外可用的、优先级高的服务器上，以解决部分雪崩效应，而该方法的缺点是没有完全解决雪崩效应，少部分用户的请求，依旧能达到响应时间高的不可用的服务器上。

技术实现要素：

本发明的目的是克服上述背景技术中不足，提供一种基于JAVA多线程技术解决物联云端服务雪崩效应的方法，可在不影响物联云其他正常功能和性能的前提下，通过对物联云系统内部JAVA线程池的改造，达到解决物联云系统的雪崩效应的目的。

为了达到上述的技术效果，本发明采取以下技术方案：

基于JAVA多线程技术解决物联云端服务雪崩效应的方法，用于物联云系统，包括以下步骤：

A.利用java线程池构造器，创建线程池并由主线程进行调用；

B.分别计算及设置线程池的核心线程数、最大线程数以及最大队列长度；其中，最大线程数大于核心线程数；

C.当有任务进来后首先判断线程池中线程数是否小于核心线程数，若线程数小于核心线程数则创建线程执行任务；否则，进入步骤D；

D.判定当前是否设有任务缓存队列，若不是，则创建任务缓存队列并将任务加入新创建的任务缓存队列中，否则，则进入步骤E；

E.判断任务缓存队列的队列长度是否小于最大队列长度，若是，则将当前任务放入任务缓存队列中，否则进入步骤F；

F.判断当前线程数是否小于最大线程数，若是，则创建线程执行任务；否则，执行拒绝策略。

进一步地，若物联云系统每秒需要处理的最小任务数量为n1、处理每个任务所需要的时间为t1，则所述步骤A中核心线程数应大于n1/(1/t1)。

进一步地，若物联云系统在80％的情况下每秒需要处理的任务数小于或等于n2；则所述步骤A中核心线程数等于n2/(1/t1)。

进一步地，若物联云系统允许的任务最大的响应时间为t2；则所述步骤A中最大队列长度等于(核心线程数/t1)*t2。

进一步地，若物联云系统每秒需要处理的最大任务数量为n3，所述步骤A中最大线程数等于(n3-最大队列长度)*(核心线程数/n2)。

进一步地，所述拒绝策略为将任务加入主线程进行处理

本发明与现有技术相比，具有以下的有益效果：

相对于现有技术中是针对服务器端的负载均衡技术，本发明的基于JAVA多线程技术解决物联云端服务雪崩效应的方法，使用的是JAVA多线程技术,且针对的点是云端服务的内部，其中，JAVA多线程技术解决云端服务雪崩效应是用户请求已经进入到服务内部后，而负载均衡技术是用户请求还在服务外部时，因此，本发明的方法是基于一种对用户请求的分配规则进行优化的技术，本发明也是是针对这一点实现对物联云系统的雪崩效应进行了优化控制，且通过本发明的方法有效防止了物联云系统雪崩效应(服务提供者的不可用导致服务调用者不可用，并将不可用逐渐放大的现象)的出现，让电视端的使用物联云系统的用户，在高峰期时的使用体验得到有效提升。

具体实施方式

下面结合本发明的实施例对本发明作进一步的阐述和说明。

实施例：

实施例一：

基于JAVA多线程技术解决物联云端服务雪崩效应的方法，用于物联云系统，包括以下步骤：

步骤一.利用java线程池构造器，创建线程池并由主线程进行调用。

步骤二.分别计算及设置线程池的核心线程数、最大线程数以及最大队列长度；其中，最大线程数大于核心线程数。

具体的，本实施例中，若每个任务需要t1秒处理，则每个线程每秒可处理1/t1个任务，而若系统每秒至少有n1个任务需要处理，则需要的线程数至少为：n1/(1/t1)，即n1*t1个线程数。且若物联云系统在80％的情况下每秒需要处理的任务数小于或等于n2；则核心线程数等于n2/(1/t1)。

如本实施例中，假设系统每秒任务数为100～1000，每个任务耗时0.1秒，则需要100*0.1至1000*0.1个线程，即10～100个线程，那么核心线程数corePoolSize应该设置为大于10，具体数字最好根据二八原则，即满足80％情况下系统每秒任务数，例如：若系统80％的情况下每秒任务数小于200，最多时为1000，则核心线程数corePoolSize可设置为20。

同时，若物联云系统允许的任务最大的响应时间为t2，如本实施例中每个任务的响应时间不得超过2秒；则最大队列长度queueCapacity等于(核心线程数/t1)*t2；如本实施例中，设定任务缓存队列的最大队列长度具体为(20/0.1)*2＝400，即任务缓存队列的最大队列长度可设置为400。

计算最大线程数maxPoolSize时，若物联云系统每秒需要处理的最大任务数量为n3，则最大线程数等于(n3-最大队列长度)*(核心线程数/n2)，如本实施例中，每秒200个任务需要20个线程，那么当每秒达到1000个任务时则需要线程数为(1000-最大队列长度)*(20/200)＝60，即最多需要60个线程，因此可将最大线程数maxPoolSize设置为60。

本发明的方法中，首先设置合理的线程池的核心线程数的值:核心线程数的值还直接决定了任务队列的长度，在创建了线程池后，核心线程数如果设置过大会导致cpu负载急剧升高，如果设置过小，用户请求的响应时间又不能得到保证。为了不让核心线程数的值过大或者过小，本方法中根据物联云系统每秒需要处理的最大任务数量n3、最小任务数量n1、处理每个任务所需要的时间t1、系统允许任务最大的响应时间t2来计算一个比较合理的核心线程数的值，从而解决了传统方法中采用默认值设置核心线程数和最大线程数，导致的由于核心线程数和最大线程数数值的设置过大或者过小，引发服务雪崩效应的产生的问题。

其次再根据核心线程数推算最大队列长度，合理的任务缓存队列长度，是保证物联云系统是否出现服务雪崩效应的关键，任务缓存队列的长度要根据核心线程数，以及系统对任务响应时间的要求来设置。队列长度设置过大，会导致任务响应时间过长，从而造成物联云系统的服务雪崩效应，传统的方法是直接初始化一个没有指定长度的队列，这实际上是将队列长度设置为Integer.MAX_VALUE，将会导致线程数量永远为核心线程数，且再也不会增加，而当任务数量陡增时，任务响应时间也将随之陡增，因此容易导致任务队列过长，当用户请求被放入任务队列后，线程池处理速度不够快导致任务没有被及时处理，用户端请求显示超时，从而出现服务雪崩效应。

步骤三.当有任务进来后首先判断线程池中线程数是否小于核心线程数，若线程数小于核心线程数则创建线程执行任务；否则，进入步骤四。

步骤四.判定当前是否设有任务缓存队列，若不是，则创建任务缓存队列并将任务加入新创建的任务缓存队列中，否则，则进入步骤五。

步骤五.判断任务缓存队列的队列长度是否小于最大队列长度，若是，则将当前任务放入任务缓存队列中，否则进入步骤六。

步骤六.判断当前线程数是否小于最大线程数，若是，则创建线程执行任务；否则，执行拒绝策略即将任务加入主线程进行处理。

本实施例中，使用java提供的拒绝策略构建方法如下：

new ThreadPoolExecutor.CallerRunsPolicy())。

作为优选，实际中，在设置上述的核心线程数、最大线程数等时，还可结合具体的硬件设备，如结合CPU的情况，则比如，当线程数量达到50时，CPU达到100％，则此时单纯的将最大线程数maxPoolSize设置为60就不是最佳方案，因为此时若系统负载长时间维持在每秒1000个任务，则将超出线程池处理能力，因此，此时应设法降低每个任务的处理时间t1。

由上可知，本实施例中，在Java线程池初始化类ThreadPoolExecutor初始化时，使用根据硬件设备计算出相应的参数，而不是采用传统方法使用默认的参数值，且首先对队列BlockingQueue的选择，在选择对LinkedBlockingDeque初始化时，设置LinkedBlockingDeque的capacity的大小，可以设置容量(queueCapacity)防止其过渡膨胀，而不是使用默认值(Integer.MAX_VALUE)。

其次，线程池初始化类ThreadPoolExecutor的拒绝策略设置，如果没有手动设置RejectedExecutionHandler拒绝策略的话，将会默认采用AbortPolicy，即如果线程池队列满了就丢掉这个任务并且抛出RejectedExecutionException异常，而丢掉的结果就是用户请求被丢弃，这里我们初始化时采用CallerRunsPolicy，使用此策略，如果添加到线程池失败，那么主线程会自己去执行该任务，不会等待线程池中的线程去执行，即当线程池无线程可用时，采用主线程继续执行相关任务，从而防止了雪崩效应的出现。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。