jon london wrote:
I like the idea of swapping out the map once the data is refreshed.. The only concern here is that there would be 2 large objects on the heap during the swap... Albeit for a short period of time.
Yes, that's one of the trade-offs. However, just like with the speed, don't go borrowing trouble by assuming it's going to be too big. You said the map can hold up to 60,000 objects, and presumably you know what those objects will look like, so it's trivial to construct a 10-line program that creates 2 maps, each holding 100,000 of those objects (to provide a margin of error) and see how much heap it eats up.
Or we could do a back of the envelope calculation.
Assume a plain old Object is 20 bytes. Then an <Object, Object> Entry in a Map is 48 bytes--two 4-byte references + two 20-byte objects. So 200,000 entries is going to be at least 9,600,000 bytes. Call it 10 M. Double it to 20M for keys + values. That should be no problem, but it's worth calculating a lower bound to see if even the best case is going to be untenable.
Now let's take a larger object. Say you use the same class for key and value, and your class's member variables are 10 Strings of 100 chars each. Now, in addition to the 48 bytes, we'll add 40 bytes (10 references to
String objects) + 200 bytes (10 String objects at 20 bytes each) + 200 bytes (10 char[] objects at 20 bytes each) + 2,000 bytes (10 char arrays of size 100, each char is 2 bytes). So now each entry is our original 20 M + (40 + 200 + 2,000) * 200,000 * 2 ~= 916 M, so call it 1G. Still not a problem for most server class hosts, but worth testing in your environment. (And for this kind of calculation, we could have saved our self some pointless nitpicking by noticing that the char[]s would dominate, so we could have just said 2,000 bytes for the chars in one object * 2 objects per Entry * 200,000 entries = 800,000,000 bytes, and then add say 10-20% for the small stuff we left out.)
Obviously these numbers are rough guesses, and the real values will depend on JVM implementation, your specific data, a bunch of smaller stuff I left out, and whatever math errors I made along the way. But they give us a reasonable idea of whether the scale is "no problem," "should be okay," "probably a tight fit," or "out of the question." Without knowing more details, I'd say this looks like, "should be okay."