Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blocking in SelectorProvider#provider #2308

Closed
valodzka opened this issue Mar 12, 2014 · 2 comments
Closed

Blocking in SelectorProvider#provider #2308

valodzka opened this issue Mar 12, 2014 · 2 comments
Assignees
Milestone

Comments

@valodzka
Copy link

Currently SelectorProvider#provider (which contains synchronized block) called for every new channel creation. This can can cause unnecessary blocking when application creates a lot of connection (performance penalty about 1% when creating 5000 connections/second).

java.nio.channels.spi.SelectorProvider.provider()
java.nio.channels.SocketChannel.open()
io.netty.channel.socket.nio.NioSocketChannel.newSocket()
io.netty.channel.socket.nio.NioSocketChannel.<init>()
sun.reflect.GeneratedConstructorAccessor12.newInstance(Object[])
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Object[])
java.lang.reflect.Constructor.newInstance(Object[])
java.lang.Class.newInstance()
io.netty.bootstrap.AbstractBootstrap$BootstrapChannelFactory.newChannel()
io.netty.bootstrap.AbstractBootstrap.initAndRegister()
io.netty.bootstrap.Bootstrap.doConnect(SocketAddress, SocketAddress)
io.netty.bootstrap.Bootstrap.connect(SocketAddress)

Possible solution is to store result of #provider and call java.nio.channels.spi.SelectorProvider#openSocketChannel directly, without SocketChannel#open.

@normanmaurer normanmaurer added this to the 4.0.18.Final milestone Mar 13, 2014
@normanmaurer normanmaurer self-assigned this Mar 13, 2014
normanmaurer pushed a commit that referenced this issue Mar 13, 2014
…ve condition when create new NIO channels.

Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
normanmaurer pushed a commit that referenced this issue Mar 13, 2014
…ve condition when create new NIO channels.

Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
normanmaurer pushed a commit that referenced this issue Mar 13, 2014
…ve condition when create new NIO channels.

Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
@junyanlai
Copy link

@fuzhengwei
Copy link

漂亮!

pulllock pushed a commit to pulllock/netty that referenced this issue Oct 19, 2023
… remove condition when create new NIO channels.

Motivation:
At the moment we use SocketChannel.open(), ServerSocketChannel.open() and DatagramSocketChannel.open(...) within the constructor of our
NIO channels. This introduces a bottleneck if you create a lot of connections as these calls delegate to SelectorProvider.provider() which
uses synchronized internal. This change removed the bottleneck.

Modifications:
Obtain a static instance of the SelectorProvider and use SelectorProvider.openSocketChannel(), SelectorProvider.openServerSocketChannel() and
SelectorProvider.openDatagramChannel(). This eliminates the bottleneck as SelectorProvider.provider() is not called on every channel creation.

Result:
Less conditions when create new channels.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants