2

I have the following infinite loop which listens for incoming messages:

public static void listenForMessages(){
          while (true) {

                dsocket.receive(receivepacket);
                byte[] rcvMsg = receivepacket.getData();



                MessageCreator tmc = new MessageCreator();
                TrafficMessage message = tmc.constructMessageFromBinary(rcvMsg);

                System.out.println("message: "+message);


        }
 }

This calls a method that reads the byte array into a string and populates a message object.

public Message constructMessageFromBinary(byte[] rcvMsg)
            throws IOException {
        ByteArrayInputStream bais = new ByteArrayInputStream(rcvMsg);
        DataInputStream dis = new DataInputStream(bais);
        StringBuffer inputLine = new StringBuffer();
        String tmp; 

        while ((tmp = dis.readLine()) != null) {
            inputLine.append(tmp);

        }

    dis.close();

        Message message = new Message();
        message.setDescriptions(tmp);

        return message;

    }

This simple process slowly leaks memory over a few hours and I receive an out of memory exception.

Is there anything wrong with this logic?

Atma
  • 29,141
  • 56
  • 198
  • 299
  • Providing a [SSCCE](http://sscce.org) would help us figure out your problem sooner. If you cannot provide us with such an example, you might want to consider profiling your application yourself. I believe JVisualVM comes with Oracle's JDK, but there are plenty of [alternatives](https://code.google.com/a/eclipselabs.org/p/jvmmonitor/) [2](https://code.google.com/p/java-profiler/) out there. – Jeffrey Jun 25 '13 at 18:03
  • 4
    There really isn't enough information here. The only two object references I see in the code presented that might leak memory, depending on what they are and how they are handled, are {dis} and {dsocket}. You can't usually leak memory from variables that are local to a block; the references are on the stack, and when the block exits, they are available for garbage collection. Normally you need to look for something that is not on the stack, or in a method that never returns. Your variables in the endless loop block are replaced each time through the loop, so that shouldn't be a leak. – arcy Jun 25 '13 at 18:04

2 Answers2

1

The problem was that I left a database connection open. I wanted to leave it open to pass data with out having to worry about stopping and starting connections. I now open and close connections each time and all is good.

Atma
  • 29,141
  • 56
  • 198
  • 299
-1

The best bet here would be to move all possible object instantiations outside the loops. For example, in the first code snippet, every iteration creates a

MessageCreator tmc.

On your second snippet, each call to the method creates a

StringBuffer inputLine.

This instantiation process may be eating away your memory slowly.

Zeh
  • 186
  • 2
  • 8
  • Garbage collection would reclaim that memory. – Jeffrey Jun 25 '13 at 18:07
  • Even if it was not null and running in the same call stack position? It is worth a try... – Zeh Jun 25 '13 at 18:19
  • @Jeffrey what are you saying the solution is then? – Atma Jun 25 '13 at 19:19
  • @Atma I have no idea. You haven't provided enough information. See the two comments on your question. – Jeffrey Jun 25 '13 at 21:21
  • @Atma while Jeffrey is correct about lack of information on the question, GC having it's own thread and profiling your app, I reckon you could try rearranging instantiations only as a test and code organization. I do believe however that the best approach is to profile since there seems to be no other acceptable answer at the moment. – Zeh Jun 25 '13 at 23:15
  • I used plumbr. It says no memory leaks detected before the program runs out of memory! Does anyone know any good profiling tools? – Atma Jun 26 '13 at 21:39
  • Now doesn't this sound like your problem? Take a look in the best answer: [Creating a memory leak with Java](http://stackoverflow.com/questions/6470651/creating-a-memory-leak-with-java?rq=1) – Zeh Jun 27 '13 at 11:36