摘要:
在业务中遇到了一种场景,在对于被请求方难以被优化的情况下,尝试通过在发送端通过线程池控制允许同时发送请求的数量,以降低直接请求服务端的压力,也要考虑请求发送失败时的重试机制;同时,需要每一次请求后的数据的集合,进行数据库的批量查询,因此使用多线程中的经典的消费者生产者模型进行控制变量,等待所有请求处理完毕后,再统一进行操作。
上干货
先来看线程池的声明,因为考虑到,线程池满了之后,也会有需要发送请求的情况,所以使用线程池工厂管理线程池;最重要的是,当线程池满的时候,执行恰当的回绝策略,优雅的处理满线程池之后的其他请求,而不是简单的拒绝。
// 线程池size
private static int threadPoolSize = 50;
private static ThreadFactory threadFactory = new EmailTaskThreadFactory();
private static RejectedExecutionHandler rejectedHandler = new EmailTaskIgnorePolicy();
// 声明一个线程池
private static ExecutorService threadpool = new ThreadPoolExecutor(threadPoolSize, threadPoolSize,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(threadPoolSize), threadFactory, rejectedHandler);
// 线程池工厂
public static class EmailTaskThreadFactory implements ThreadFactory{
private static final AtomicInteger poolNumber = new AtomicInteger(1);
private final ThreadGroup group;
private final AtomicInteger threadNumber = new AtomicInteger(1);
private final String namePrefix;
EmailTaskThreadFactory(){
SecurityManager s = System.getSecurityManager();
group = (s != null) ? s.getThreadGroup() : Thread.currentThread().getThreadGroup();
namePrefix = "EmailTaskThreadPool - " + poolNumber.getAndIncrement() + " - thread - ";
}
@Override
public Thread newThread(Runnable r) {
Thread t = new Thread(group, r, namePrefix + threadNumber.getAndIncrement(), 0);
if(t.isDaemon()){
t.setDaemon(false);
}
if (t.getPriority() != Thread.NORM_PRIORITY){
t.setPriority(Thread.NORM_PRIORITY);
}
return t;
}
}
public static class EmailTaskIgnorePolicy implements RejectedExecutionHandler{
@Override
public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) {
// 线程池满时的回绝策略
LOGGER.error(r.toString() + "job is rejected, because the thread pool is full!");
// 判断线程池状态,等待一段时间后,再次执行
if(!executor.isShutdown()) {
try {
Thread.sleep(10L);
} catch (InterruptedException e) {
LOGGER.error("回绝策略执行时,等待报错: ", e);
}
if (executor.getQueue().size() < executor.getMaximumPoolSize()) {
executor.execute(r);
}
}
}
}
然后,考虑使用生产者,进行HTTP请求的发送处逻辑
if(taskRejectFlag.get() > 0){
// 等待一段时间,再去请求服务方
// 这里是我设置的一个AtomicInteger变量,会随定时器的执行,逐渐变小
taskRejectFlag.getAndDecrement();
}
for(int i = 0;i < registrys.size();i++){
RegistryDTO registry = registrys.get(i);
Runnable thread = new Runnable() {
@Override
public void run() {
List<String> parentNode = null;
try {
if (taskRejectFlag.get() == 0) {
parentNode = /** 发送HTTP请求,查询所需信息 **/;
}
} catch (IOException e) {
// 发送请求失败时的重试机制
int errorCode = Integer.parseInt(e.getMessage());
if (errorCode != 404) {
try {
Thread.sleep(10L);
parentNode = /** 发送HTTP请求,查询所需信息 **/;
} catch (IOException ex) {
LOGGER.error("发送HTTP请求到服务方查询,重试失败。");
} catch (InterruptedException ex) {
LOGGER.error("重试请求到服务方等待时,报错:", ex);
}
} else {
// 服务器挂了,停止查询服务方
// 对应上面的判断,会等待1小时
taskRejectFlag.set(60);
}
}
// 原子操作,+1
taskSendEmailFlag.getAndIncrement();
// 只有当发送请求的实际数量taskSendEmailFlag(也是个AtomicInteger变量)和发送请求的总数量相等时,才执行如下操作,唤醒主线程
if (taskSendEmailFlag.get() == registrys.size()) {
try {
synchronized (lock) {
lock.notify();
}
}catch (IllegalMonitorStateException e){
LOGGER.error("唤醒线程等待队列时,出错:", e);
}
}
}
};
threadpool.execute(thread);
}
然后,考虑使用消费者,主线程在等待所有子线程执行完毕之后,被唤醒以执行后续操作
try{
synchronized (lock) {
// 挂起主线程,等待所有子线程执行完毕后唤醒主线程
if (taskSendEmailFlag.get() != registrys.size()) {
LOGGER.info("挂起线程,等待查询服务方后再继续");
lock.wait();
}
// 业务逻辑业务逻辑
// 业务逻辑业务逻辑
// 业务逻辑业务逻辑
}
} catch (IllegalMonitorStateException | InterruptedException e) {
LOGGER.error("等待查询服务方时,线程进行后续操作时报错:", e);
}
// 所有定时器逻辑执行完毕后,恢复为0
taskSendEmailFlag.set(0);
感谢能看到最后。