Go channel vs Java BlockingQueue

huangapple go评论92阅读模式
英文:

Go channel vs Java BlockingQueue

问题

Go通道和Java BlockingQueue之间有什么区别吗?两者都是具有类似阻塞和内存模型语义的队列。可选地,两者都可以设置容量。

英文:

Are there any differences between a Go channel and a Java BlockingQueue? Both are queues with similar blocking and memory model semantics. Optionally both can have a capacity set.

答案1

得分: 22

我会说最大的区别是Go通道支持select语句,它允许您执行一次通道操作。一个例子(改编自Go语言规范):

select {
case i1 = <-c1:
    print("从c1接收到", i1, "\n")
case c2 <- i2:
    print("将", i2, "发送到c2\n")
case i3, ok := <-c3:  // 等同于:i3, ok := <-c3
    if ok {
        print("从c3接收到", i3, "\n")
    } else {
        print("c3已关闭\n")
    }
}

在这个例子中,将执行接收来自c1、发送到c2或从c3接收的操作中的一个。进入select时,会随机选择一个就绪的通道(如果有)。否则,操作将阻塞,直到其中一个通道就绪。

我不知道有什么简单的方法可以使用Java工具模拟这种通道选择。有人可能会认为这是select语句的属性,而不是通道设计的一部分,但我认为这是通道设计的基本特性。

英文:

I would say the biggest difference is that Go channels have support for the select statement, which allow you to perform exactly one channel operation. An example (altered from the Go language specification):

select {
case i1 = &lt;-c1:
	print(&quot;received &quot;, i1, &quot; from c1\n&quot;)
case c2 &lt;- i2:
	print(&quot;sent &quot;, i2, &quot; to c2\n&quot;)
case i3, ok := (&lt;-c3):  // same as: i3, ok := &lt;-c3
	if ok {
		print(&quot;received &quot;, i3, &quot; from c3\n&quot;)
	} else {
		print(&quot;c3 is closed\n&quot;)
	}
}

In this example, exactly one of the receive-from-c1, send-to-c2, or receive-from-c3 operations will be performed. When entering the select, a ready channel (if any) is selected randomly. Otherwise, the operation blocks until one of the channels is ready.

I'm not aware of any trivial way to model this channel selection using the Java utilities. One could argue that this is a property of the select statement rather than the design of channels, but I would argue that it's fundamental to the design of channels.

答案2

得分: 10

另一个非常重要的区别是:你可以关闭一个Go通道来表示没有更多的元素要传递。在Java中是不可能的。

例如:goroutine A读取一个文件列表。它将每个文件发布到通道中。在最后一个文件之后,它关闭通道。goroutine B从通道中读取文件并以某种方式处理它们。通道关闭后,goroutine退出。

在Java中很难实现这一点;然而,一些解决方法存在。

英文:

One more very important difference is: You can close a Go channel to signal that no more elements are coming. That is not possible using Java.

Example: goroutine A reads a list of files. It posts each file into the Channel. After the last file, it closes the channel. goroutine B reads the files from the channel and processes them in some way. After the channel is closed, the goroutine quits.

Doing this in Java is not easily possible; however some workarounds exist.

答案3

得分: 4

它们可以以类似的方式使用。

  • 在放置/发送或接收时,两者都可以阻塞。
  • 两者都有一个容量,决定了何时发送将被阻塞。

最大的区别可能是go通道比java对象要便宜得多,并且go通道可以限制只发送或只接收,这可以确保一些额外的类型强制执行,以确定谁可以从通道发送和接收。

英文:

They can be used in similar ways.

  • Both can block on when putting/sending or taking/recieving.
  • Both have a capacity that governs when sending will block.

The biggest differences are probably that go channels are considerably cheaper than a java object. and that go channels can be restricted to only send or only receive which can ensure some additional type enforcement regarding who can send and who can receive from a channel.

答案4

得分: 3

要在Java中实现类似于Golang的select语句,需要使用java.nio包。具体来说,需要使用选择器(selectors)和通道(channels)。请查看此处的包文档:

http://docs.oracle.com/javase/6/docs/api/java/nio/channels/package-summary.html#multiplex

它提供了与Golang的select语句几乎相同的功能,使用单个线程来复用从多个通道读取/写入的操作。

英文:

To do something similar to golang'select statement in java would involve using the java.nio package. Specifically selectors and channels. Check out the package docs here:

http://docs.oracle.com/javase/6/docs/api/java/nio/channels/package-summary.html#multiplex

It offers pretty much the same capability as the golang select statement, using a single thread to multiplex reading/writing from multiple channels.

huangapple
  • 本文由 发表于 2012年5月22日 02:14:07
  • 转载请务必保留本文链接:https://go.coder-hub.com/10690403.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定