I'm building a Java application that retrieves trade data from a database based on accounts, but I'm struggling with memory issues. The challenge is that account trade volumes vary significantly, and during high trading days, I sometimes end up loading too much data at once, leading to out-of-memory errors. Currently, I'm selecting accounts randomly from a HashSet and loading trades for each account in parallel across 16 threads. However, on busy days, this method overwhelms the system's memory.
I need suggestions on how to implement a better scheduling strategy that controls account loading to prevent these memory issues. It's essential to load all trades for each account—there's no possibility for batching without a complete redesign of the app. Additionally, the trading workflow is very time-sensitive, and I already have the trade counts per account, allowing me to estimate the memory requirements. Any advice on creating a more memory-efficient and performance-oriented trade loading approach would be greatly appreciated!
1 Answer
It sounds like you really need a semaphore to help manage your memory usage. By creating one with permits equal to your estimated memory needs, you can ensure that your threads only load data when there's enough memory available. If a thread needs more memory than what's left, it will simply wait until some gets freed up when other tasks complete. But remember, Java's garbage collector may leave ghost objects in memory for a bit, so make sure you tune your GC settings carefully. Just be cautious, since this method can reduce concurrency if one task hogs all the memory permits! However, you might want to integrate resource management into your task selection too for better balance, though that can get complex if you're not deeply versed in concurrent programming.
I appreciate the detailed explanation! Just to clarify, when you mention estimating available memory, were you referring to the JVM's runtime memory? This could end up being quite pessimistic if so. Also, regarding the headroom, my app typically uses up to 90% memory during peak times and then drops back to 30% after garbage collection. If I leave too much headroom, I might waste resources and hurt performance.