Discussion :

[ToTo13]

Bonjour,

j'ai une classe dans laquelle je créé des threads que je stocke dans un tableau :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
if ( threads == null || threads.length != nbCPU )
		{
		nbFreeThreads = 0 ; // Aucun thread n'est pour l'instant utilisable.
		StopThreads() ; // On tue éventuellement ce qu'il doit l'être.
 
		threads = new FuzzyGLRthread[nbCPU] ; // Création du nouveau tableau
 
		for (i=0 ; i < nbCPU ; i++)
			{
			threads[i] = new FuzzyGLRthread() ;
			threads[i].start() ;
			}
 
		synchronized (this) // Je vérifie / attends que les threads démarrent.
			{
			while ( nbFreeThreads != nbCPU ) // On attends la fin de la creation de chaque thread.
				try	{
					wait() ;
					}
				catch ( InterruptedException e )
					{
					e.printStackTrace() ;
					}
			}
		}

Afin de m'assurer que mes threads soient correctement tués, j'utilise cette méthode :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
private void StopThreads()
	{
	if ( threads == null ) return ;
	for (int i=0 ; i < threads.length ; i++)
		try {
			threads[i].interrupt() ; // Wait its death.
			threads[i].join() ; // Wait its death.
			threads[i] = null ;
			}
		catch ( InterruptedException ex )
			{
			System.err.println("Souci") ;
			}
	threads = null ;
	System.gc() ;
	}

Je fais cela, parce que la classe utilisant cette méthode est appelée un TRES grands nombre de fois, donc je souhaite être certains que je n'ai pas de threads encore actifs.

Mais voilà, durant l'exécution, j'ai cette exception :

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at imageTiTi.reducer.FuzzyGLR.Reduce(FuzzyGLR.java:147)
at characterization.textures.thibaultmatrices.fuzzy.szm.MultiFuzzySZM.Compute(MultiFuzzySZM.java:173)
at softwares.challenges.icip2013.CharacterizeCells.Process(CharacterizeCells.java:120)
at prototyper.Prototyper.main(Prototyper.java:295)
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at imageTiTi.reducer.FuzzyGLR.Reduce(FuzzyGLR.java:147)
at characterization.textures.thibaultmatrices.fuzzy.szm.MultiFuzzySZM.Compute(MultiFuzzySZM.java:173)
at softwares.challenges.icip2013.CharacterizeCells.Process(CharacterizeCells.java:120)
at prototyper.Prototyper.main(Prototyper.java:295)
Exception in thread "main" java.lang.NullPointerException
at utils.LogFile.addNewError(LogFile.java:80)
at softwares.challenges.icip2013.CharacterizeCells.Process(CharacterizeCells.java:140)
at prototyper.Prototyper.main(Prototyper.java:295)

Et là attention, je dois tuer le processus via mon système car NetBeans n'arrive même pas à le faire.

Est ce que quelqu'un saurait d'où vient le problème ?

[OcterA]

Salut,
D'après la stackTrace, tu n'as plus de mémoire. Lance tu ton appli avec des arguments spécifique pour la JVM? (notamment -Xmx).
Tes threads sont t'il consommateur en mémoire? Brancher une Jconsole sur ton appli te permettrais peut être de voir l'état de la mémoire de la JVM ainsi que ce que tu consomme et surtout qu'est-ce qui te prend ta mémoire.

PS : A priori tu as une NPE dans ta gestion des logs, peut-être que à cause de cette NPE tu ne voie pas toutes les erreurs.

[ToTo13]

Merci pour la réponse.

D'après la stackTrace, tu n'as plus de mémoire. Lance tu ton appli avec des arguments spécifique pour la JVM? (notamment -Xmx).
Tes threads sont t'il consommateur en mémoire? Brancher une Jconsole sur ton appli te permettrais peut être de voir l'état de la mémoire de la JVM ainsi que ce que tu consomme et surtout qu'est-ce qui te prend ta mémoire.

La classe qui utilise ce morceau de code ne gère au maximum que 4 threads.
Avant de tuer la classe (la mettre à nulle), j'appelle la méthode pour tuer les threads qu'elle gère.
Et comme les threads ne gèrent normalement pas ou peu de mémoire, je n'ai aucune raison de déborder.

PS : A priori tu as une NPE dans ta gestion des logs, peut-être que à cause de cette NPE tu ne voie pas toutes les erreurs.

C'est quoi ?

[ToTo13]

J'ai modifié ma méthode StopThreads afin qu'elle dise au thread de se suicider : il appelle lui même la méthode "interrupt", puis un break pour sortir de la méthode run().

Cela me permet d'aller quatre fois plus loin dans le traitement de mes données, mais la même erreur survient :

java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:658)
at imageTiTi.reducer.FuzzyGLR.Reduce(FuzzyGLR.java:149)
at characterization.textures.thibaultmatrices.fuzzy.szm.MultiFuzzySZM.Compute(MultiFuzzySZM.java:173)
at softwares.challenges.icip2013.CharacterizeCells.Process(CharacterizeCells.java:120)
at prototyper.Prototyper.main(Prototyper.java:295)

Qu'est ce que je ne comprends pas ?

[ToTo13]

En fait mon bricolage fonctionne correctement (bien ???). J'avais oublié un cas qui faisait qu'une fois sur trois je ne tuais pas les threads avant la classe, du coup cela me permettait de faire plus de calcul avant explosion.

Information : j'ai vérifié la mémoire utilisée pendant l'exécution (en utilisant MemoryMXBean) et la JVM gère correctement via le ramasse miettes, car je ne dépasse jamais 30%.
C'est le nombre de thread (libérant pourtant la mémoire qu'ils utilisent) qui fait en fait tout exploser.

Même si cela fonctionne désormais, est ce la bonne façon de faire ?

[OcterA]

Salut,
Le NPE est un NullPointerException : les trois dernières lignes de ton log.
Concernant la mémoire tu as regarder que la mémoire principale de la JVM ou aussi les autres? (PermGenSpace,...)

[thelvin]

De manière générale il est bien vu de ne pas passer son temps à détruire/créer des threads, mais plutôt de se créer un seul pool de threads qu'on utilisera pendant toute la durée de vie de l'application, et de leur confier des tâches à exécuter en parallèle.

Cette approche est déjà implémentée par ThreadPoolExecutor qui s'occupe de gérer les threads. Il suffit de le créer en disant combien de threads, puis de lui confier les tâches à accomplir, à chaque fois qu'on en a.

Mais ça ne m'explique pas vraiment ce qui t'arrive. Ce n'est pas très bon de détruire/créer des threads sans arrêt, mais ça devrait marcher quand même, juste pas être très efficace.

[adiGuba]

Salut,

Mais ça ne m'explique pas vraiment ce qui t'arrive. Ce n'est pas très bon de détruire/créer des threads sans arrêt, mais ça devrait marcher quand même, juste pas être très efficace.

C'est juste que l'exception est un peu trompeuse : ce n'est pas réellement un OutOfMemory dans le sens où la mémoire n'est pas saturé.

C'est juste que la limite de thread de l'OS a été atteinte, et qu'il refuse donc d'en créer de nouveaux.

Si la méthode est appelée un grand nombre de fois et que certains threads ne sont pas arrêté proprement cela peut arriver très vite...



Lorsqu'on manipule des ressources (threads, fichiers, sockets...) la moindre erreur de ce coté là peut être catastrophique si on multiplie les appels...


a++

[ToTo13]

Bonjour,

merci pour les exécution.
Concernant vos questions :
- oui, j'avais regardé les différentes mémoires.
- ce que je faisais était en fait comparable à un ThreadPoolExecutor.
- je crée normalement le minimum de thread, que je réutilise. J'ai d'ailleurs refait une version en ce sens où je ne crée que le minimum de classe nécessaire, donc aussi de threads.
Ce qui m'a trompé, c'est que lorsque je mettais à null la classe qui contenait les threads, je pensais que ces derniers étaient tués.

Merci à tous.

[thelvin]

Je ne comprends pas comment tu peux,
- d'une part, réutiliser des threads
- d'autre part, chercher à en tuer.
C'est contradictoire. Si tu les tues ils ne sont pas réutilisables.

Par ailleurs, les threads n'ont rien à voir avec des classes, ce sont des instances.

[ToTo13]

Je ne comprends pas comment tu peux,
- d'une part, réutiliser des threads
- d'autre part, chercher à en tuer.
C'est contradictoire. Si tu les tues ils ne sont pas réutilisables.

Par ailleurs, les threads n'ont rien à voir avec des classes, ce sont des instances.

Mes threads sont intanciés depuis une classe qui en a besoin.
Sauf que cette classe est appelée de très nombreuses fois avec à chaque fois des configurations totalement différentes.
La plupart du temps j'arrive à réutiliser la même classe en modifiant la configuration, mais pas là, c'est pour cela que je devais instancier un grand nombre de fois la classe et donc les threads. Du coup, je voulais tuer les threads qui n'étaient plus utiles.

[thelvin]

D'accord, donc ça n'a rien à voir avec ce que fait ThreadPoolExecutor. Je suggère d'utiliser ThreadPoolExecutor.

[ToTo13]

Sur d'autres classes manipulant des threads, j'ai testé ThreadPoolExecutor. Le travail est le même et je n'ai pas de gain de performances.
J'avais fait cela avant de connaître TPE. Cela m'a permis de comprendre ce qui se passait.