blocks|key|2621473|text|在Java中，你可以有很多线程。线程一直在做自己的事情，直到它在某个地方被阻塞(通常是在互斥或I/O操作上)。当然，这不会阻塞其他线程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2621474|多线程应用程序的基本场景是，当等待阻塞的线程会引入太多等待时，您将使用多个线程。这里“太多”的定义完全取决于你，但一般来说，这是你如何通过更好地利用资源来实现更好的性能。|2621475|然而，Java中线程的工作方式有一些限制。当线程在Java“外部”的某个地方被阻塞时，例如在OS调用或外部(本机)库中，大多数(如果不是全部)是阻塞的。理论上，如果本机代码阻塞了线程，Java对此无能为力。通常，这应该不是问题，除非本机代码有bug。|2621476|因此，在阻塞JDBC响应的情况下，您将创建一个新线程，该线程将在第一线程等待数据库完成时执行其他工作。或者，您可以只为执行JDBC而创建一个线程。你可以让它完全按照你想要的那样(使用监听器等)但操作系统施加的限制除外。所以这是可能的，但是JDBC驱动程序可能没有提供开箱即用的功能。核心Java中已经有很多基础设施，你可能会发现它们很有用(线程池、工作线程、同步集合)。但与任何多线程一样，您需要非常小心地同时访问来自不同线程的数据。|2621477|从Java+7开始，还支持非阻塞I/O+(NIO)。这几乎就是您所描述的。I/O被卸载到操作系统，因此您的操作会立即返回，并且在操作完成时会得到一个回调。然而，并不是所有的库都支持NIO。对于我的工作，我从来没有理由使用它，因为我总是可以用我的线程实现相同的东西，至少一样好。|2621478|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

In Java, you can have many threads. A thread is doing its stuff until it is blocked somewhere (typically, on a mutex or a I/O operation). Of course, this does not block other threads.

The fundamental scenario of multithreaded applications is that you use multiple threads when waiting for a blocked thread would introduce too much waiting. Definition of "too much" here depends entirely on you, but in general, this is how you achieve beter performance through better utilization of resources.

There are some limitations in how threads in Java work, however. Most, if not all of them are when the thread is blocked somewhere "outside" of Java such as in OS call or external (native) library. Theoretically, if native code blocks a thread, Java can not do anything about it. Normally, this should not be a problem unless the native code has a bug.

So in the case of a blocking JDBC response, you would create a new thread which would do other work while first thread is waiting for database to complete. Alternatively, you could make a thread just for doing JDBC. You could make it exactly like you want (with listeners etc.) except for limitations imposed by OS. So it's possible, but it's probably not provided out-of-the-box by JDBC drivers. There is a lot of infrastructure already in core Java which you might find useful (thread pools, workers, synchronized collections). But as with any multithreading, you need to be very careful with accessing data from different threads simultaneously.

Since Java 7, there is also support for non-blocking I/O (NIO). This is almost exactly what you are describing. I/O is offloaded to OS, so your operations return immediately and you get a callback when the operation is finished. However, not all libraries support NIO. For my work, I have never had a reason to use it, because I could always implement the same stuff with my threads at least as good.

blocks|key|2411046|text|如果问题是“Java的当前架构是否真的是一个线程对应一个阻塞操作”，而“阻塞操作”指的是“数据库操作”，那么答案是否定的。目前可用于Java的大多数数据库驱动程序都是基于jdbc的，并且确实是这样工作的。但也有可用的替代方案(https://spring.io/blog/2016/11/28/going-reactive-with-spring-data)和更多的替代方案(+https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database，https://dzone.com/articles/spring-5-webflux-and-jdbc-to-block-or-not-to-block)。有关该功能的工作原理，请参阅How+is+ReactiveMongo+implemented+so+that+it+is+considered+non-blocking?|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2411047|对于jdbc，还有包装jdbc调用(Wrapping+blocking+I/O+in+project+reactor、Spring+webflux+and+reading+from+database+)和采用这种方法的项目(https://dzone.com/articles/myth-asynchronous-jdbc)的方法。|2411048|entityMap|0|LINK|mutability|MUTABLE|url|https://spring.io/blog/2016/11/28/going-reactive-with-spring-data|1|https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database|2|https://dzone.com/articles/spring-5-webflux-and-jdbc-to-block-or-not-to-block|3|https://stackoverflow.com/questions/25618259/how-is-reactivemongo-implemented-so-that-it-is-considered-non-blocking|4|https://stackoverflow.com/questions/47505778/wrapping-blocking-i-o-in-project-reactor|5|https://stackoverflow.com/questions/42299455/spring-webflux-and-reading-from-database|6|https://dzone.com/articles/myth-asynchronous-jdbc^0|35|1T|0|59|2K|1|7U|25|2|AF|1Z|3|0|I|14|4|1N|14|5|34|1D|6|0^^$0|@$1|2|3|4|5|6|7|Z|8|@]|9|@$A|10|B|11|1|12]|$A|13|B|14|1|15]|$A|16|B|17|1|18]|$A|19|B|1A|1|1B]]|C|$]]|$1|D|3|E|5|6|7|1C|8|@]|9|@$A|1D|B|1E|1|1F]|$A|1G|B|1H|1|1I]|$A|1J|B|1K|1|1L]]|C|$]]|$1|F|3|-4|5|6|7|1M|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]|R|$5|I|J|K|C|$L|S]]|T|$5|I|J|K|C|$L|U]]|V|$5|I|J|K|C|$L|W]]|X|$5|I|J|K|C|$L|Y]]]]

If the question is whether the "current architecture in Java really is one thread per one blocking operation" and by "blocking operation" you mean "database operation" then the answer is no. Most database drivers available for Java currently are jdbc-based and do work that way. But there are usable alternatives (<a href="https://spring.io/blog/2016/11/28/going-reactive-with-spring-data" rel="nofollow noreferrer">https://spring.io/blog/2016/11/28/going-reactive-with-spring-data</a>) and more on the way (
<a href="https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database" rel="nofollow noreferrer">https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database</a> , <a href="https://dzone.com/articles/spring-5-webflux-and-jdbc-to-block-or-not-to-block" rel="nofollow noreferrer">https://dzone.com/articles/spring-5-webflux-and-jdbc-to-block-or-not-to-block</a>). For how this works see <a href="https://stackoverflow.com/questions/25618259/how-is-reactivemongo-implemented-so-that-it-is-considered-non-blocking">How is ReactiveMongo implemented so that it is considered non-blocking?</a>

For jdbc there are also ways to wrap the jdbc calls (<a href="https://stackoverflow.com/questions/47505778/wrapping-blocking-i-o-in-project-reactor">Wrapping blocking I/O in project reactor</a> , <a href="https://stackoverflow.com/questions/42299455/spring-webflux-and-reading-from-database">Spring webflux and reading from database</a> ) and projects pursuing this approach (<a href="https://dzone.com/articles/myth-asynchronous-jdbc" rel="nofollow noreferrer">https://dzone.com/articles/myth-asynchronous-jdbc</a>)

I have been thinking about why JDBC is only blocking operation and why I can't set some listener to the hypothetical event handler onResultSetArrived(ResultSet rs). Why I have to block single one thread per each JDBC query.

After a while I've dive into Java Sockets (I suppose JDBC is build on top of them) and realised that there also isn't any event handling. Only option to provide non-blocking read is through the available() method but this is very inefficient as it has to be checked periodically in the loop.

As far as I'm aware, interruption is fundamental thing in PC. It goes down from the hardware up to the operating system. In the Java it can be implemented into event driven approach in read value from Socket.

Now, my question is am I missing something and there exists some workaround or current architecture in Java really is one thread per one blocking operation? And if yes isn't it inefficient?

Why Java Socket doesn't support interruption handling?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我一直在思考为什么JDBC只阻塞操作，为什么我不能将一些侦听器设置为假设的事件处理程序onResultSetArrived(ResultSet rs)。为什么我必须为每个JDBC查询阻塞一个线程。过了一段时间后，我深入研究了Java Sockets (我认为JDBC是建立在它们之上的)，并意识到也没有任何事件处理。提供...

问为什么Java套接字不支持中断处理？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java套接字不支持中断处理？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java套接字不支持中断处理？
EN