Java obtener memoria disponible

Nota: Todas las respuestas hasta ahora, incluso la aceptada, parecen responder a la pregunta diciendo que Runtime.getRuntime().freeMemory() le da la cantidad de memoria que se puede asignar hasta que ocurra un error de falta de memoria. Sin embargo: esto está mal.

El aproximado cantidad de memoria que se puede asignar hasta que se produce un error de falta de memoria, es decir, la memoria libre es probable

long presumableFreeMemory = Runtime.getRuntime().maxMemory() - allocatedMemory;

Donde

long allocatedMemory      = (Runtime.getRuntime().totalMemory()-Runtime.getRuntime().freeMemory());

Explicación: Si inicia la JVM a través de un parámetro-mx (o-Xmx) especifica la cantidad máxima disponible para la JVM. Runtime.getRuntime().maxMemory() le dará esta cantidad. A partir de esta cantidad de memoria del sistema, la JVM asignará memoria en trozos, por ejemplo, bloques de 64 mb. Al principio, la JVM solo asignará un fragmento del sistema y no la cantidad total. Runtime.getRuntime().totalMemory() da la memoria total asignada del sistema, mientras que Runtime.getRuntime().freeMemory()le da la memoria libre dentro de la memoria total asignada.

Por lo tanto:

long definitelyFreeMemory = Runtime.getRuntime().freeMemory();

Es la memoria libre ya reservado por la JVM, pero es probable que solo una pequeña cantidad. Y probablemente obtendrá presumableFreeMemory. Por supuesto, puede obtener una excepción fuera de memoria incluso si intentó asignar una cantidad menor que presumableFreeMemory. Esto puede suceder si la JVM no obtiene el siguiente fragmento de memoria del sistema. Sin embargo, en la mayoría de los sistemas esto nunca sucederá y el sistema comenzará a intercambiar, una situación que le gustaría evitar. W. r. t. a la pregunta original: si-mx se establece en un valor razonable, entonces presumableFreeMemory es una buena indicador de la memoria libre.

Además de usar los métodos de tiempo de ejecución, puede obtener información de memoria adicional utilizando

MemoryMXBean memBean = ManagementFactory.getMemoryMXBean();
MemoryUsage heap = memBean.getHeapMemoryUsage();
MemoryUsage nonheap = memBean.getNonHeapMemoryUsage();

Cada MemoryUsage proporciona valores init, used, committed y max. Esto podría ser útil si crea un subproceso de monitor de memoria que sondee la memoria y la registre, proporcionándole un historial de uso de memoria a lo largo del tiempo. A veces es útil ver el uso de memoria a lo largo del tiempo que conduce a los errores.

Si realmente quieres llevar esto a un extremo, crea un volcado de montón hilo. Monitoree su uso de memoria a lo largo del tiempo y cuando supere ciertos umbrales haga lo siguiente (esto funciona en JBoss 5.0 - su kilometraje puede variar):

// init code
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
HotSpotDiagnosticMXBean diagBean = ManagementFactory.newPlatformMXBeanProxy(server, "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class); 

// loop code
// add some code to figure if we have passed some threshold, then

File heapFile = new File(outputDir, "heap-" + curThreshold + ".hprof");
log.info("Dumping heap file " + heapFile.getAbsolutePath());
diagBean.dumpHeap(heapFile.getAbsolutePath(), true);

Más tarde puede revisar estos archivos de volcado de pilas con eclipse memory analyzer o herramientas similares para verificar fugas de memoria, etc.

Además de la otra respuesta, me gustaría señalar que hacer eso no es necesariamente una buena idea, ya que es posible que tenga una caché en su aplicación que use SoftReferences.

Tal caché liberaría memoria tan pronto como la JVM alcance sus límites de memoria. La asignación de memoria, incluso si no hay suficiente memoria libre, primero causaría que la memoria sea liberada por las referencias suaves, y la haría disponible para la asignación.

Para obtener la memoria disponible en todo el sistema operativo, agregue OSHI usando la siguiente dependencia maven:

<dependency>
    <groupId>com.github.dblock</groupId>
    <artifactId>oshi-core</artifactId>
    <version>LATEST</version>
</dependency>

Luego, en Java, use el siguiente código:

SystemInfo si = new SystemInfo();
HardwareAbstractionLayer hal = si.getHardware();
long availableMemory = hal.getMemory().getAvailable();

Siempre puedes llamar a Runtime.getRuntime().freeMemory().

La otra mitad del problema, obtener el costo de los objetos, me parece más problemático.

Creo que una mejor solución sería averiguar cómo agrupar y escalar sus servicios web para que puedan aceptar con gracia el 150% de la carga nominal sin negar nuevas conexiones. Parece que un ejercicio de dimensionamiento te daría una mejor solución que un hackeo de código.

long freeMemory = Runtime.getRuntime().freeMemory();

Runtime.getRuntime().freeMemory() es una forma de obtener memoria libre para JVM en ese momento mientras se ejecuta. ¿Es buena manera (o) no depende completamente de su aplicación.