Java Threading - Alternatief voor het spawnen van een enorme hoeveelheid threads

Ik ben momenteel bezig met het maken van een simulatieprogramma om klanten te simuleren die zich verplaatsen op de kaart van een massaal online multiplayer-game. Ik moet een raster hebben om de kaart weer te geven, die Client-objecten bevat. Deze clients moeten willekeurig door het raster bewegen, waarbij elk communiceert met een serverobject.

Op dit moment start ik een nieuwe thread voor elke client en roept hij een methode op in zijn server met een willekeurige bewegingsrichting elke seconde.

Dit werkt goed totdat ik begin met het toevoegen van een groot aantal clients (~ 5000), waarbij het programma crasht en ik de uitzondering "java.lang.OutOfMemoryError: geen nieuwe native thread maken" kan maken.

Is er een alternatieve manier om met zo'n grote hoeveelheid clients om te gaan zonder dat ze elk een aparte thread vormen?

Bedankt, Dan

0
Er zijn veel benaderingen. Welke waarschijnlijk het beste is, hangt af van wat je doelen zijn. En ook als de server een computer op afstand is waarmee je praat via het netwerk of een lokaal proces.
toegevoegd de auteur Affe, de bron
heb je overwogen, gebruik dan een thread poor lib, kijk hier stackoverflow.com/vragen/5148561/open-source-threadpool-l & zwnj; ib
toegevoegd de auteur Prasanna Talakanti, de bron

3 antwoord

Waarom geef je in godsnaam elke klant zijn eigen thread? Gewoon een thread doen doe het volgende:

for (;;) {
    for (Client c : clients) {
        c.update();
    }
    Thread.sleep(1000);
}

Dat heeft het voordeel dat eerlijkheid wordt gegarandeerd (alle clients worden bijgewerkt, zelfs als het systeem overbelast is) en de server hoeft niet te worden beveiligd. Bovendien is een for-loop veel efficiënter dan het wisselen van threads, verbruikt minder geheugen (elke thread heeft een stack toegewezen).

4
toegevoegd
Ik ben het eens met dit antwoord, dit is een klassiek voorbeeld van overdreven gebruik van draadsnijden. Als u wilt dat de clients willekeurig worden uitgevoerd, kiest u een willekeurig nummer en werkt u die client bij.
toegevoegd de auteur David, de bron
Is het scenario een belastingtest? Dat wil zeggen, wordt het netwerk gesimuleerd of een echt gebruikt? De vraag luidt dat de clients in een verzameling worden bewaard, dus in een enkele VM. Ook zegt de vraag dat methoden worden aangeroepen op het server -object , wat me doet geloven dat er daadwerkelijke servers bij betrokken zijn.
toegevoegd de auteur meriton, de bron
Ervan uitgaande dat het scenario een belastingstest is, is het niet echt een test om ze allemaal achter elkaar te doen!
toegevoegd de auteur Affe, de bron
Een tekortkoming van de vraag, niet van uw antwoord :) +1
toegevoegd de auteur Affe, de bron
Jongens, bedankt je opmerkingen. Het netwerk is inderdaad gesimuleerd en wordt in een enkele VM uitgevoerd, maar de gesimuleerde omgeving bevat tientallen servers, evenals de vele clients. Ik zal de sequentiële methode gebruiken en kijken of mijn testresultaten werkbaar zijn. Bedankt!
toegevoegd de auteur dlwells02, de bron

Heb je erover nagedacht om het gelijkheidsmodel van de actor te gebruiken? Akka biedt hiervoor een volwassen, op bibliotheken gebaseerde actorimplementatie. Hiermee kunt u enorme hoeveelheden objecten maken die met elkaar kunnen communiceren door middel van het doorgeven van berichten. Het wordt ondersteund door een threadpool.

http://akka.io/docs/akka/1.2/java/untyped -actors.html

2
toegevoegd
Akka is gebruikt voor MMO's
toegevoegd de auteur Viktor Klang, de bron
Bedankt hiervoor! Ik zal ernaar kijken en het testen!
toegevoegd de auteur dlwells02, de bron

Er zijn twee manieren die ik kan bedenken uit de top van mijn hoofd.

1 - Laat elke thread een verzameling klanten bevatten.

In plaats van slechts 1 client per thread. Probeer een verzameling X-clients per thread te hebben. Loop vervolgens door de clients en verplaats ze allemaal.

2 - Verdien uw klanten echt

Gebruik een JMeter of andere gedistribueerde testsuite om threads over meerdere computers te verspreiden.

1
toegevoegd