Parallel threads can speed up a process that spends time waiting for something outside the JVM to happen. Retrieving a web page is a good example. Your JVM executes zero instructions while waiting for a response over the network, so another
thread would have a good opportunity to run. At the opposite end, a process that is CPU bound, maybe doing some deep math, would not be a good candidate for threading because the CPU just doesn't have time to run another process.
So with that in mind, how many threads? Good question! You could try adding more and more until you saturate the CPU or the network, then back off a bit so you're not making the JVM work so hard on thread management that it can't do your real work. The whole 1,000 would probably be a Bad Thing.
How do you control the number of threads and know when they're done? The number is easy. If you're in JDK5 look at thread pooling with the Executor class. In earlier JDKs get another thread pool, maybe from Apache Commons. Both are pretty easy to use. You can put your 1,000 requests into a queue as Commands and know you are done when the queue is empty. Hmm, not quite, you'd only know when all the commands have been picked up and started, not finished. Any other ideas on how to know when you're done? The number of values in the map equals the number of commands? Might hang forever if one command threw an exception and never put a result in the map.