Java Reference
In-Depth Information
Memory Profiling
Although CPU utilization may seem like the place you're most likely to see issues, the truth is that it is
my experience that memory issues are more likely to pop up in your software. The reason is that you use
a number of frameworks that do things behind the scenes. When you use these frameworks incorrectly,
large numbers of objects can be created without any indication that it has occurred until you run out of
memory completely. This section looks at how to profile memory usage using VisualVM.
To look at how to profile memory, let's tweak the same PricingTierItemProcessor you did
previously. However, this time instead of taking up processing time, you update it to simulate creating a
collection that is out of control. Although the code example may not be what you see in real-world
systems, accidentally creating collections that are larger than you expect is a common reason for
memory issues. Listing 11-2 shows the code for the updated PricingTierItemProcessor .
Listing 11-2. PricingTierItemProcessor with a Memory Leak
package com.apress.springbatch.statement.processor;
import java.util.ArrayList;
import java.util.List;
import org.springframework.batch.item.ItemProcessor;
import com.apress.springbatch.statement.domain.AccountTransactionQuantity;
import com.apress.springbatch.statement.domain.PricingTier;
public class PricingTierItemProcessor implements
ItemProcessor<AccountTransactionQuantity, AccountTransactionQuantity> {
private List<PricingTier> accountsProcessed = new ArrayList<PricingTier>();
public AccountTransactionQuantity process(AccountTransactionQuantity atq)
throws Exception {
if(atq.getTransactionCount() <= 1000) {
} else if(atq.getTransactionCount() > 1000 && atq.getTransactionCount() <= 100000) {
} else if(atq.getTransactionCount() > 100000 &&
atq.getTransactionCount() <= 1000000) {
} else {
for(int i = 0; i <atq.getTransactionCount() * 750; i++) {
return atq;
Search WWH ::

Custom Search