As a general guiding principle, avoid "One Thread Per User" designs, especially for networking. Managing thread interactions is a known hard problem, and having an uncertain number of threads drives that complexity.
A thread per major functional category is more manageable, and scales nicer with actual multiple cores. (@Alan Wolfe's comment alludes to this.) A thread for physics, a thread for management console, a thread for networking...
deal with high ping players
(I confess, I've only done very simple client-side Java networking, not recently, so I'm not fluent in server side asynch for Java. But it looks like java.nio.channels.AsynchronousXxx are the relevant classes.)
Now, behind the scenes, the i/o system may be using threads... but they're trained professionals, that is, it's mission critical and they've worked the bugs out so we don't have to.