As my game is purely multiplayer, online performance is important.
Should I run two threads for each player/connection? (One for input and one for output) or should I run one thread for all player input and one thread for all player output?
What is the pros and cons, and how do I deal with high ping players in the second method?
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
The same way as with fast-ping players: you never (ever!!) block on network access. What you want is known as "asynchronous i/o". It can take various forms, such as event callbacks to your code from the i/o system (like JavaScript), or look like one master polling loop (like *NIX select() call).
(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.
