How to prevent memory leaks during design phase of a component?

The most memory leaks occurs by implementation faults, in Java most based on an not sufficient understanding of the used technology. (for example 4 different kind of inner classes) The only way that helps here is spend time and money to the developers skills. - Best reading Effective Java Second Edition by Joshua Bloch An other area that causes often memory leeks is concurrency.

- To my knowledge, the best way to deal with this (and other concurrency problems) is to define which components need to be tread save (and which run in a single thread environment) BEFORE implementing them. And if they need to be thread save implemented, then define BEFORE implementing who EXACTLY they are ensure that they are thread save (which function and method is guarded by what) The last thing you can do in design, pay attention to static fields One other think you can do by design is to build an watchdog. If you have (for example) a dynamic list, where it is not a big problem when some items of the list get lost, and you know the list can be the cause for some trouble (failures in threading or implementation), than implement a watchdog that clear the list if it becomes much bigger than you ever expect.(And then: fix the bug that causes the problem!) - An example for such a list could be an stock exchange GUI update event list (in a not stock relevant web site).

If one course update is not send to the client, but the next one (one second later), then the lost of one update is much better than crashing the whole server.

The most memory leaks occurs by implementation faults, in Java most based on an not sufficient understanding of the used technology. (for example 4 different kind of inner classes) The only way that helps here is spend time and money to the developers skills. - Best reading Effective Java Second Edition by Joshua Bloch An other area that causes often memory leeks is concurrency.

- To my knowledge, the best way to deal with this (and other concurrency problems) is to define which components need to be tread save (and which run in a single thread environment) BEFORE implementing them. And if they need to be thread save implemented, then define BEFORE implementing who EXACTLY they are ensure that they are thread save (which function and method is guarded by what). The last thing you can do in design, pay attention to static fields.

One other think you can do by design is to build an watchdog. If you have (for example) a dynamic list, where it is not a big problem when some items of the list get lost, and you know the list can be the cause for some trouble (failures in threading or implementation), than implement a watchdog that clear the list if it becomes much bigger than you ever expect. (And then: fix the bug that causes the problem!) - An example for such a list could be an stock exchange GUI update event list (in a not stock relevant web site).

If one course update is not send to the client, but the next one (one second later), then the lost of one update is much better than crashing the whole server.

One of the most common case of memory leak at java is with caching: Map userConnection = new HashMap(); // cache connections: userConnection. Put("User X", connectionInstance); // connectionInstance is closed but never the userConnection. Remove("User X") is called.

When the connection is closed, this mapping is not cleared, having a memory leak. Answering your question, put at your guide lines to use WeakHashMap ( http://download.oracle.com/javase/6/docs/api/java/util/WeakHashMap.html ) for caching rather than to use the "normal" HashMap.

1 - this usually bites after a few months, once you've ramped up the load/number of users/whatever. – SimonJ May 2 at 11:01.

It is not only memory you should be concerned about. Resources such as threading, files, and network connections are also to be considered. I can recommend you to read the book Pattern-Oriented Software Architecture, Volume 3: Patterns for Resource Management.It contains some useful patterns to take into consideration.

I don't believe you can prevent memory leaks in design phase. However using traditional load testing tools like JMeter/Grinder/Loadrunner and such can help discover memory leaks so they can be fixed before a release. Performance testing should be involved in every step of the development process, just like unit testing and integration testing.

Loading up the system is only one half of the challenge in uncovering the resource leaks. The second challenge is having a proper system of monitors and diagnostic utilities in place to understand how resources are being used, and potentially impinged. Ultimately the resource leaks really fall into four broad categories: Memory, Disk, Network and CPU.

Whether you are looking at your app code, a guest operating system like Java or a Database, or the core operating system, all of the metrics you can collect are subset of these items. Because monitoring can have an overhead on the system performance engineering staff tend to go light at the top level stats until an issue is identified and then deploy deeper level monitoring in the class of the identified resource leak for both the core and guest OS's to find out the likely cause. If you are looking for some lightweight deep diagnostics which can help in profiling all of the way back into the unit test and component assembly stages and then carry the same tools all the way through performance testing efforts then I can recommend solutions from this organization, rtiperformance.com/.James Pulley Moderator: SQAForums Loadrunner|WinRunner, GoogleGroups lr-loadrunner, YahooGroups LoadRunner|Advanced-LoadRunner, LinkedIn LoadRunner (owner)| LoadRunnerbyTheHour (owner).

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.