blocks|key|4502351|text|由于Scala在Java虚拟机上运行，并且(在幕后)使用Java+API进行I/O，因此切换到scala不太可能提供比编写良好的Java代码更好的性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4502352|至于解决方案，你对这个问题的描述太粗略了，不能推荐具体的解决方案。|4502353|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Since Scala runs on the Java Virtual Machine, and (under the hood) uses the Java API for I/O, switching to scala is unlikely to offer better performance than well written Java code.

As for solutions, your description of the problem is far too sketchy to recommend particular solutions.

blocks|key|4784415|text|您是否正在使用或尝试使用Java+nio+(非阻塞)？开发人员报告了高达300%25的性能提升。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4784416|Java+NIO+FileChannel+versus+FileOutputstream+performance+/+usefulness+(请同时参考本文)|offset|length|4784417|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/q/1605332/931607^0|0|0|1X|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Are you using or tried Java nio ( non blocking) ? Developers report upto 300% performance increase.

<a href="https://stackoverflow.com/q/1605332/931607">Java NIO FileChannel versus FileOutputstream performance / usefulness</a> ( Please refer this as well)

blocks|key|4784457|text|通常，当人们抱怨Java+IO很慢时，是他们对IO所做的事情很慢，而不是IO本身。例如，BufferedReader读取文本行(相对较慢)可以读取90MB/s，而使用合适的CPU/HDD。您可以使用内存映射文件使其更快，但除非您的磁盘驱动器能够处理它，否则不会有太大的不同。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4784458|您可以采取一些措施来提高IO性能，但您很快就会发现，提高IO速度的方法是改进硬件。|4784459|如果您使用的硬盘可以保持100+MB/s的读取速度和120+IOPS，您将受到这些因素的限制，将该驱动器替换为具有500+MB/s和80,000+IOPS的SSD将会更快。|4784460|同样，如果您使用的是100+Mb/s网络，则可能只有12+MB/s，在1+GB/s网络上可能会达到110+MB/s，而在10+GB-E网络上，您可能会幸运地获得1+Gb/s。|4784461|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Usually when people complain that Java IO is slow, it is what they are doing with the IO which is slow, not the IO itself. E.g. BufferedReader reading lines of text (which is relatively slow) can read 90 MB/s with a decent CPU/HDD. You can make it much faster with memory mapped files but unless your disk drive can handle it, it won't make much real difference.

There are things you can do to improve IO performance but you quickly find that the way to get faster IO is to improve the hardware.

If you are using a Hard Drive which can sustain 100 MB/s read speed and 120 IOPS, you are going to limited by these factors and replacing the drive with an SSD which does 500 MB/s and 80,000 IOPS is going to be faster.

Similarly, if you are using a 100 Mb/s network, you might only get 12 MB/s, on a 1 Gb/s network you might get 110 MB/s and on a 10 Gig-E network you might be lucky to get 1 GB/s.

blocks|key|2887139|text|如果您正在执行许多微小的I/O操作，那么将它们合并到一个大型I/O操作中可以极大地提高代码的速度。函数式编程技术倾向于使数据收集和转换操作更易于编写(例如，您可以将待处理输出的项存储在列表中，并使用map将项到文本或项到二进制的转换器应用于它们)。否则，函数式编程技术不能克服固有的慢通道。如果在Java和其他地方，原始I/O速度有限，并且您有足够的硬件线程可用，那么对于每个独立的I/O通道，您应该有一个最高优先级的线程，并且让它只执行I/O+(不进行数据转换，不执行任何操作)。这将最大化您的I/O速率，然后您可以使用其他线程进行转换和业务逻辑等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2887140|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you are performing many tiny I/O operations, then coalescing them into one large I/O operation could greatly speed up your code. Functional programming techniques tend to make data collection and conversion operations easier to write (e.g. you can store items for pending output in a list, and use map to apply an item-to-text or item-to-binary converter to them). Otherwise, no, functional programming techniques don't overcome inherently slow channels. If raw I/O speed is limiting, in Java and elsewhere, and you have enough hardware threads available, you should have one top priority thread for each independent I/O channel, and have it perform only I/O (no data conversion, nothing). That will maximize your I/O rate, and then you can use the other threads to do conversions and business logic and such.

blocks|key|673159|text|一个问题是你是否有无限的时间来开发你的应用程序。如果您有无限的时间，那么Java程序和Scala程序将具有相同的性能，因为您可以编写生成与Java完全相同的字节码的Scala程序。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|673160|但是，如果你有无限的时间，为什么不用C(或汇编语言)开发呢？你会得到更好的表现。|673161|另一个是你的IO代码有多复杂。如果它是非常微不足道的东西，那么Scala可能不会提供太多好处，因为没有足够的“肉”来利用它的特性。|673162|我认为如果你有有限的时间和复杂的IO代码库，基于Scala的解决方案可能会更快。Scala打开了许多习惯用法的大门，而这些习惯用法在Java中编写起来太费力了，所以人们会避免使用它们，并在以后付出代价。|673163|例如，在Java语言中使用ForkJoinPool并行执行一个数据集合上的计算，您必须创建它，然后创建一个包装计算的类，为每个项目拆分它并提交到池中。|673164|在Scala中：collection.par.map(calculation)。编写这段代码比Java快得多，所以您只需这样做，就可以有空闲时间来处理其他问题。|offset|length|style|CODE|673165|从个人经验来看，我有一个相关的故事。我在一篇博客文章中读到，BuildR是一个基于ruby的构建工具，对于简单的构建，它比Maven2快两倍。考虑到Ruby大约比Java慢20倍，我很惊讶。所以我给Maven做了侧写。事实证明，它对同一个XML文件进行了1000次apx解析。当然，通过精心设计，他们本可以将这一点减少到只有一次。但我猜他们没有这样做的原因是因为Java中的直截了当的方法导致了复杂的设计，并在之后进行了更改。使用BuildR，设计更简单，性能更好。在Scala中，您可以感受到在动态语言中编程的感觉，同时在性能方面仍然与Java不相上下。|673166|更新:考虑更多，Scala中有一些区域将提供比Java更好的性能(同样，假设IO瓶颈是由于包装IO操作的代码，而不是字节的读/写)：*懒惰的参数和值-可以将花费的CPU周期推到实际需要它们的时候*+Specialization+-允许告诉编译器为本机类型创建通用数据结构的副本，从而避免装箱、拆箱和强制转换。|673167|entityMap^0|0|0|0|0|0|8|V|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@$L|11|M|12|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|14|8|@]|9|@]|A|$]]|$1|T|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|U|$]]

One question is whether you have unlimited time to develop your application or not. If you have unlimited time, then the Java program and Scala programs will have the same performance since you can write Scala programs that will produce exactly the same bytecode as Java.

But, if you have unlimited time, why not develop in C (or assembler)? You'd get better performance.

Another is how sophisticated your IO code is. If it is something quite trivial, then Scala will probably not provide much benefit, as there is not enough "meat" to utilize its features.

I think if you have limited time and a complex IO codebase, the a Scala based solution may be faster. The reason Scala opens the door to many idioms that in Java are just too laborious to write, so people avoid them and pay the price later. 

For example, executing a calculation over a collection of data in parallel is done in Java with ForkJoinPool, which you have to create, then create a class wrapping the calculation, break it for each item and submit to the pool. 

In Scala: <code>collection.par.map(calculation)</code>. Writing this is much faster than Java, so you just do it and have spare time to tackle other issues.

From personal experience, I have a related story. I read in a blog article that BuildR, a ruby based build tool was two times faster than Maven for a simple build. Considering that Ruby is about 20 times slower than Java, I was surprised. So I profiled Maven. It turned out it did apx 1000 times parsing of the same XML file. Now of course with careful design, they could have reduced that to just one time. But I guess the reason they did not is because the strait-forward approach in Java led to a design to complex to change after. With BuildR, the design was simpler and performance better. In Scala, you get the feeling of programming in a dynamic language while still being on par with Java in terms of performance.

UPDATE: Thinking about it more, there are some areas in Scala which will give greater performance than Java (again, assuming the IO bottleneck is because of the code that wraps the IO operations, not the reading/writing of bytes):
* Lazy arguments and values - can push spending CPU cycles to when they are actually required
* Specialization - allows to tell the compiler to create copies of generic data structures for the native types, thus avoiding boxing, unboxing and casting.

Hi: We are using Java for a multi thread application. We found bottleneck at Java I/O. Has functional programming, scala for example, had better I/O throughput? We will have many cores cpu, in that sense, business logic could be handled very fast, but I/O would be a bottleneck. Are there any good solution?

I/O functional programming, and java programming

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

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

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

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

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

嗨:我们正在使用Java开发一个多线程应用程序。我们发现了Java I/O的瓶颈。例如，函数式编程，scala，有更好的I/O吞吐量吗？我们将有许多核心cpu，从这个意义上说，业务逻辑可以非常快地处理，但I/O将是一个瓶颈。有什么好的解决方案吗？

问I/O函数式编程和java编程
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问I/O函数式编程和java编程EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问I/O函数式编程和java编程
EN