使用线程执行框架的一次经历

开发 架构
一个线程从某个地方接收消息(数据),可以是其他主机或者消息队列,然后转由另外的一个线程池来执行具体处理消息的逻辑,并且消息的处理速度小于接收消息的速度。这种情景很常见,试想一下,你会怎么设计和实现?

场景

一个线程从某个地方接收消息(数据),可以是其他主机或者消息队列,然后转由另外的一个线程池来执行具体处理消息的逻辑,并且消息的处理速度小于接收消息的速度。这种情景很常见,试想一下,你会怎么设计和实现?

直观想法

很显然采用JUC的线程框架,可以迅速写出代码。

消息接收者:

 

  1. public class Receiver { 
  2.     private static volatile boolean inited = false
  3.     private static volatile boolean shutdown = false
  4.     private static volatile int cnt = 0
  5.  
  6.     private MessageHandler messageHandler; 
  7.  
  8.     public void start(){ 
  9.         Executors.newSingleThreadExecutor().execute(new Runnable() { 
  10.             @Override 
  11.             public void run() { 
  12.                 while(!shutdown){ 
  13.                     init(); 
  14.                     recv(); 
  15.                 } 
  16.             } 
  17.         }); 
  18.     } 
  19.  
  20.     /** 
  21.      * 模拟消息接收 
  22.      */ 
  23.     public void recv(){ 
  24.             Message msg = new Message("Msg" + System.currentTimeMillis()); System.out.println(String.format("接收到消息(%d): %s", ++cnt, msg)); messageHandler.handle(msg); } public void init(){ if(!inited){ messageHandler = new MessageHandler(); inited = true; } } public static void main(String[] args) { new Receiver().start(); 
  25.     } 

消息处理:

 

  1. public class MessageHandler { 
  2.  
  3.     private static final int THREAD_POOL_SIZE = 4
  4.  
  5.     private ExecutorService service = Executors.newFixedThreadPool(THREAD_POOL_SIZE); 
  6.  
  7.     public void handle(Message msg) { 
  8.         try { 
  9.             service.execute(new Runnable() { 
  10.                 @Override 
  11.                 public void run() { 
  12.                     parseMsg(msg); 
  13.                 } 
  14.             }); 
  15.         } catch (Throwable e) { 
  16.             System.out.println("消息处理异常" + e); } } /** * 比较耗时的消息处理流程 */ public void parseMsg(Message message) { while (true) { try { System.out.println("解析消息:" + message); Thread.sleep(5000); System.out.println("============================"); } catch (InterruptedException e) { 
  17.                 e.printStackTrace(); 
  18.             } 
  19.  
  20.         } 
  21.     } 

效果:这种方案导致的现象是接收到的消息会迅速堆积,我们从消息队列(或者其他地方)取出了大量消息,但是处理线程的速度又跟不上,所以导致的问题是大量的Task会堆积在线程池底层维护的一个阻塞队列中,这会极大的耗费存储空间,影响系统的性能。

分析:当execute()一个任务的时候,如果有空闲的worker线程,那么投入运行,否则看设置的***线程个数,没有达到线程个数限制就创建新线程,接新任务,否则就把任务缓冲到一个阻塞队列中,问题就是这个队列,默认的大小是没有限制的,所以就会大量的堆积任务,必然耗费heap空间。

 

  1. public static ExecutorService newFixedThreadPool(int nThreads) { 
  2.         return new ThreadPoolExecutor(nThreads, nThreads, 
  3.                                       0L, TimeUnit.MILLISECONDS, 
  4.                                       new LinkedBlockingQueue<Runnable>()); 
  5.     } 
  6.  
  7. public LinkedBlockingQueue() { 
  8.         this(Integer.MAX_VALUE); // capacity 
  9.     } 

计数限制

面对上述问题,想到了要限制消息接收的速度,自然就想到了各种线程同步的原语,不过在这里最简单的就是使用一个Volatile的计数器。

消息接收者:

 

  1. public class Receiver { 
  2.     private static volatile boolean inited = false
  3.     private static volatile boolean shutdown = false
  4.     private static volatile int cnt = 0
  5.     private MessageHandler messageHandler; 
  6.     public void start(){ 
  7.         Executors.newSingleThreadExecutor().execute(new Runnable() { 
  8.             @Override 
  9.             public void run() { 
  10.                 while(!shutdown){ 
  11.                     init(); 
  12.                     recv(); 
  13.                 } 
  14.             } 
  15.         }); 
  16.     } 
  17.  
  18.     /** 
  19.      * 模拟消息接收 
  20.      */ 
  21.     public void recv(){ 
  22.             Message msg = new Message("Msg" + System.currentTimeMillis()); System.out.println(String.format("接收到消息(%d): %s", ++cnt, msg)); messageHandler.handle(msg); } public void init(){ if(!inited){ messageHandler = new MessageHandler(); inited = true; } } public static void main(String[] args) { new Receiver().start(); 
  23.     } 

消息处理:

 

  1. public class MessageHandler { 
  2.     private static final int THREAD_POOL_SIZE = 1
  3.     private ExecutorService service = Executors.newFixedThreadPool(THREAD_POOL_SIZE); 
  4.  
  5.     public void handle(Message msg){ 
  6.         try { 
  7.             service.execute(new Runnable() { 
  8.  
  9.                 @Override 
  10.                 public void run() { 
  11.                     parseMsg(msg); 
  12.                 } 
  13.             }); 
  14.         } catch (Throwable e) { 
  15.             System.out.println("消息处理异常" + e); } } /** * 比较耗时的消息处理流程 */ public void parseMsg(Message message){ try { Thread.sleep(10000); System.out.println("解析消息:" + message); } catch (InterruptedException e) { e.printStackTrace(); }finally { 
  16.             Receiver.limit --; 
  17.         } 
  18.  
  19.     } 

效果:通过控制消息的个数来阻塞消息的接收过程,就不会导致任务的堆积,系统的内存消耗会比较平缓,限制消息的个数本质就和下面限制任务队列大小一样。

使用同步队列 SynchronousQueue

SynchronousQueue 虽名为队列,但是其实不会缓冲任务的对象,只是作为对象传递的控制点,如果有空闲线程或者没有达到***线程限制,就会交付给worker线程去执行,否则就会拒绝,我们需要自己实现对应的拒绝策略RejectedExecutionHandler,默认的是抛出异常RejectedExecutionException。

消息接收者同上。

消息处理:

 

  1. public class MessageHandler { 
  2.     private static final int THREAD_POOL_SIZE = 4
  3.  
  4.     ThreadPoolExecutor service = new ThreadPoolExecutor(THREAD_POOL_SIZE, THREAD_POOL_SIZE, 0L, TimeUnit.MILLISECONDS, 
  5.             new SynchronousQueue<Runnable>(), new RejectedExecutionHandler() { 
  6.         @Override 
  7.         public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { 
  8.             System.out.println("自定义拒绝策略"); try { executor.getQueue().put(r); System.out.println("重新放任务回队列"); } catch (InterruptedException e) { e.printStackTrace(); } } }); public void handle(Message msg) { try { System.out.println(service.getTaskCount()); System.out.println(service.getQueue().size()); System.out.println(service.getCompletedTaskCount()); service.execute(new Runnable() { @Override public void run() { parseMsg(msg); } }); } catch (Throwable e) { System.out.println("消息处理异常" + e); } } /** * 比较耗时的消息处理流程 */ public void parseMsg(Message message) { while (true) { try { System.out.println("线程名:" + Thread.currentThread().getName()); System.out.println("解析消息:" + message); Thread.sleep(1000); } catch (InterruptedException e) { 
  9.                 e.printStackTrace(); 
  10.             } 
  11.         } 
  12.     } 

效果:能够控制消息的接收速度,但是我们需要在rejectedExecution中实现某种阻塞的操作,但是选择在发生拒绝的时候把任务重新放回队列,带来的问题就是这个Task会发生饥饿现象。

[[178175]]

使用大小限制的阻塞队列

使用LinkedBlockingQueue作为线程框架底层的任务缓冲区,并且设置大小限制,思想上和上述方案一样,都是有一个阻塞的点,但是通过***的jvm monitor看到这里的CPU消耗更少,内存使用有所降低,并且波动小(具体原因有待探索)。

消息接收者同上。

消息处理:

  1. public class MessageHandler { 
  2.     private static final int THREAD_POOL_SIZE = 4
  3.     private static final int BLOCK_QUEUE_CAP = 500
  4.     ThreadPoolExecutor service = new ThreadPoolExecutor(THREAD_POOL_SIZE, THREAD_POOL_SIZE, 0L, TimeUnit.MILLISECONDS, 
  5.             new LinkedBlockingQueue<Runnable>(BLOCK_QUEUE_CAP), new SimpleThreadFactory(), new RejectedExecutionHandler() { 
  6.         @Override 
  7.         public void rejectedExecution(Runnable r, ThreadPoolExecutor executor) { 
  8.             System.out.println("自定义拒绝策略"); try { executor.getQueue().put(r); System.out.println("重新放任务回队列"); } catch (InterruptedException e) { e.printStackTrace(); } } }); public void handle(Message msg) { try { service.execute(new Runnable() { @Override public void run() { parseMsg(msg); } }); } catch (Throwable e) { System.out.println("消息处理异常" + e); } } /** * 比较耗时的消息处理流程 */ public void parseMsg(Message message) { try { Thread.sleep(5000); System.out.println("线程名:" + Thread.currentThread().getName()); System.out.println("解析消息:" + message); } catch (InterruptedException e) { e.printStackTrace(); } } static class SimpleThreadFactory implements ThreadFactory { @Override public Thread newThread(Runnable r) { Thread thread = new Thread(r); thread.setName("Thread-" + System.currentTimeMillis()); return thread; 
  9.         } 
  10.     } 

总结

多线程是比较容易出问题的地方,特别当对方法不熟悉的时候

 

责任编辑:张燕妮 来源: Chown
相关推荐

2012-08-28 09:21:59

Ajax查错经历Web

2023-03-29 09:36:32

2021-12-06 19:29:17

LRU内存算法

2013-04-01 10:27:37

程序员失业

2011-04-13 09:21:30

死锁SQL Server

2013-01-17 10:31:13

JavaScriptWeb开发firebug

2021-04-13 18:17:48

Hbase集群配置

2014-08-06 11:24:24

Elasticsear劫持挂马

2021-01-22 05:35:19

Lvm模块Multipath

2012-07-12 14:35:31

面试经历

2015-04-28 15:31:09

2018-09-14 10:48:45

Java内存泄漏

2022-06-10 11:06:23

服务下线

2017-11-09 09:06:29

流量暴增优化

2020-11-23 07:13:13

Nodejs源码

2019-04-04 15:00:40

SQL索引数据库

2020-07-15 08:11:05

Linuxc++程序

2022-07-13 08:31:18

React问题排查

2018-12-06 16:25:39

数据库服务器线程池

2020-02-10 10:15:31

技术研发指标
点赞
收藏

51CTO技术栈公众号