SynchronousQueue不存储元素，每次插入需等待移除，适用于线程间直接数据传递；公平模式确保等待时间最长的线程优先，避免饥饿，适合实时系统，但性能开销大；非公平模式提升吞吐量，减少上下文切换，适合高并发场景如日志处理；put()和take()方法阻塞直至配对线程就绪，实现数据同步传递；tryTransfer()可非阻塞尝试传递数据，支持超时，提高响应性；Executors.newCachedThreadPool()使用SynchronousQueue，动态创建线程执行短期任务，但可能因无限制创建线程导致资源耗尽；避免死锁需防止循环等待，不应在同一线程中同时调用put()和take()，建议使用超时或外部协调机制。
SynchronousQueue本质上是一种特殊的阻塞队列，它不存储任何元素。 每次插入操作必须等待一个相应的移除操作，反之亦然。 想象一下，它就像一个电话亭，只有当有人打电话进来，同时有人在里面等待接听，这个通话才能建立。 这使得它非常适合在线程之间直接传递数据，特别是在生产者-消费者模式中。
SynchronousQueue使用技巧
如何选择公平模式和非公平模式的SynchronousQueue？
SynchronousQueue提供了公平和非公平两种模式，通过构造函数中的
fair
参数来控制。 公平模式（
new SynchronousQueue<>(true)
）保证等待时间最长的线程优先获得资源，而非公平模式（
new SynchronousQueue<>(false)
或默认构造函数）则允许任何线程立即尝试获取资源，这可能导致某些线程一直等待。
选择哪种模式取决于你的应用场景。 如果你需要确保每个线程都有公平的机会获得资源，避免饥饿现象，那么公平模式是更好的选择。 然而，公平模式通常会带来更高的性能开销，因为它需要维护等待队列的顺序。
立即学习“Java免费学习笔记（深入）”；
非公平模式则可能提供更高的吞吐量，因为它允许线程竞争资源，减少了上下文切换的开销。 但需要注意的是，非公平模式可能导致某些线程长时间无法获得资源，从而影响系统的整体响应时间。
例如，在构建一个高性能的日志系统时，我们可能更倾向于使用非公平模式，因为日志处理的吞吐量比单个线程的公平性更重要。 而在构建一个实时交易系统时，我们可能需要使用公平模式，以确保每个交易请求都能得到及时处理。
// 公平模式 SynchronousQueue<String> fairQueue = new SynchronousQueue<>(true); // 非公平模式 SynchronousQueue<String> unfairQueue = new SynchronousQueue<>(false);
SynchronousQueue的
put()
put()
和
take()
方法是如何工作的？
put()
方法用于将元素插入队列，但由于SynchronousQueue不存储元素，
put()
方法会阻塞，直到另一个线程调用
take()
方法来移除该元素。 同样，
take()
方法也会阻塞，直到另一个线程调用
put()
方法来插入一个元素。
这种阻塞机制使得SynchronousQueue成为线程之间直接交换数据的理想选择。 想象一下，一个线程调用
put()
方法，就像在电话亭里等待对方接听电话，而另一个线程调用
take()
方法，就像接听电话一样。 只有当两个线程都准备好时，数据才能成功传递。
// 生产者线程 new Thread(() -> { try { System.out.println("生产者准备放入数据"); fairQueue.put("Hello, World!"); System.out.println("生产者放入数据完成"); } catch (InterruptedException e) { e.printStackTrace(); } }).start(); // 消费者线程 new Thread(() -> { try { Thread.sleep(1000); // 模拟一些耗时操作 System.out.println("消费者准备获取数据"); String message = fairQueue.take(); System.out.println("消费者获取到数据: " + message); } catch (InterruptedException e) { e.printStackTrace(); } }).start();
如何使用
tryTransfer()
tryTransfer()
方法进行非阻塞的数据传递？
tryTransfer()
方法是SynchronousQueue提供的一个非阻塞方法，它尝试将元素传递给等待的消费者线程，如果立即没有消费者线程等待，则立即返回
false
，而不是阻塞。 这使得我们可以在不阻塞线程的情况下尝试进行数据传递。
tryTransfer()
方法可以接受一个超时参数，用于指定等待消费者线程的最长时间。 如果在指定的时间内没有消费者线程等待，则返回
false
。
使用
tryTransfer()
方法可以避免线程长时间阻塞，提高系统的响应性。 例如，在一个高并发的系统中，我们可能不希望生产者线程因为等待消费者线程而长时间阻塞，这时就可以使用
tryTransfer()
方法进行非阻塞的数据传递。
// 生产者线程 new Thread(() -> { try { System.out.println("生产者尝试放入数据"); boolean transferred = fairQueue.tryTransfer("Hello, World!", 500, TimeUnit.MILLISECONDS); if (transferred) { System.out.println("生产者放入数据成功"); } else { System.out.println("生产者放入数据失败，没有消费者等待"); } } catch (InterruptedException e) { e.printStackTrace(); } }).start(); // 消费者线程 new Thread(() -> { try { Thread.sleep(1000); // 模拟一些耗时操作 System.out.println("消费者准备获取数据"); String message = fairQueue.take(); System.out.println("消费者获取到数据: " + message); } catch (InterruptedException e) { e.printStackTrace(); } }).start();
SynchronousQueue在线程池中的应用：
Executors.newCachedThreadPool()
Executors.newCachedThreadPool()
Executors.newCachedThreadPool()
方法创建的线程池使用SynchronousQueue作为其工作队列。 当线程池接收到一个新的任务时，它会尝试将任务直接传递给一个空闲的线程来执行。 如果没有空闲线程，线程池会创建一个新的线程来执行该任务。 如果线程执行完任务后，在指定的时间内没有新的任务到达，该线程会被回收。
这种机制使得
newCachedThreadPool()
非常适合执行大量的短期任务。 因为它可以根据任务的到达情况动态地创建和销毁线程，从而最大限度地利用系统资源。
然而，
newCachedThreadPool()
也存在一些缺点。 由于它会无限制地创建线程，如果任务的到达速度超过了线程的处理速度，可能会导致系统资源耗尽。 因此，在使用
newCachedThreadPool()
时，需要谨慎评估任务的负载情况，避免出现资源耗尽的问题。
ExecutorService executor = Executors.newCachedThreadPool(); for (int i = 0; i < 10; i++) { final int taskIndex = i; executor.execute(() -> { try { System.out.println("线程 " + Thread.currentThread().getName() + " 正在执行任务 " + taskIndex); Thread.sleep(1000); // 模拟一些耗时操作 System.out.println("线程 " + Thread.currentThread().getName() + " 完成任务 " + taskIndex); } catch (InterruptedException e) { e.printStackTrace(); } }); } executor.shutdown();
如何避免在使用SynchronousQueue时出现死锁？
使用SynchronousQueue时，最常见的死锁情况是当两个线程都在互相等待对方释放资源时发生。 例如，线程A尝试
put()
数据到队列，而线程B也在尝试
take()
数据，但它们都在等待对方先执行操作。
为了避免死锁，需要仔细设计线程之间的交互逻辑，确保不会出现循环等待的情况。 可以考虑使用超时机制，或者使用更复杂的同步机制来协调线程之间的操作。
另外，避免在一个线程中同时进行
put()
和
take()
操作，因为这很容易导致死锁。 最好将
put()
和
take()
操作放在不同的线程中执行，并使用适当的同步机制来协调它们之间的操作。
评论（已关闭）
评论已关闭