Domanda

Sto scrivendo un semplice gioco di dama in Java.Quando passo il mouse sulla scheda, il mio processore aumenta fino al 50% (100% su un core).

Vorrei scoprire quale parte del mio codice (supponendo che sia colpa mia) sia in esecuzione durante questo.

Ho provato a eseguire il debug, ma in questo caso il debug passo-passo non funziona molto bene.

C'è qualche strumento che può dirmi dove si trova il mio problema?Attualmente sto utilizzando Eclipse.

È stato utile?

Soluzione

Questa si chiama "profilazione".Il tuo IDE probabilmente ne include uno:Vedere Profiler Open Source in Java.

Altri suggerimenti

Utilizzare un profiler (ad es il tuokit )

Profilazione?Non so quale IDE stai utilizzando, ma Eclipse ha un profilo decente e c'è anche un elenco di alcuni profiler open source su Java-source.

In poche parole, profiler ti dirà quale parte del tuo programma viene chiamata e quante volte.

Non profilo molto i miei programmi, quindi non ho molta esperienza, ma ho giocato con il file IDE NetBeans profiler mentre lo stavo testando.(Di solito uso anche Eclipse.Esaminerò anche le funzionalità di profilazione in Eclipse.)

Il profiler NetBeans ti dirà quale thread è stato in esecuzione per quanto tempo e quali metodi sono stati chiamati per quanto tempo e ti fornirà grafici a barre per mostrare quanto tempo ha impiegato ciascun metodo.Questo dovrebbe darti un suggerimento su quale metodo sta causando problemi.Puoi dare un'occhiata a Profilatore Java fornito dall'IDE NetBeans, se sei curioso.

La profilazione è una tecnica che viene solitamente utilizzata per misurare quali parti di un programma richiedono molto tempo di esecuzione, che a sua volta può essere utilizzata per valutare se eseguire ottimizzazioni sarebbe utile o meno per aumentare le prestazioni di un programma.

Buona fortuna!

1) È colpa tua :)

2) Se stai utilizzando eclipse o netbeans, prova a utilizzare le funzionalità di profilazione: dovrebbe dirti abbastanza rapidamente dove il tuo codice trascorre molto tempo.

3) in caso contrario, aggiungi l'output della console dove ritieni che sia il ciclo interno: dovresti riuscire a trovarlo rapidamente.

Sì, ci sono tali strumenti:devi profilare il codice.Puoi provare TPTP in eclissi o forse provarci JProfiler.Ciò ti consentirà di vedere cosa viene chiamato e quanto spesso.

Usa un profiler.Ci sono molti.Ecco un elenco: http://java-source.net/open-source/profilers.Ad esempio puoi usare JIP, un profiler codificato Java.

Trifoglio fornirà un bel rapporto che mostra il conteggio dei risultati per ogni riga e ramo.Per esempio, questa linea è stato giustiziato 7 volte.

Sono disponibili plugin per Eclipse, Maven, Ant e IDEA.È gratuito per open source, oppure puoi ottenere un file Licenza di valutazione di 30 giorni.

Se utilizzi Sun Java 6, vengono fornite le versioni JDK più recenti JVisualVM nella directory bin.Si tratta di uno strumento capace di monitoraggio e profilazione che richiederà uno sforzo minimo da utilizzare - non è nemmeno necessario avviare il programma con parametri speciali - JVisualVM elenca semplicemente tutti i processi Java attualmente in esecuzione e tu scegli quello con cui vuoi giocare .

Questo strumento ti dirà quali metodi utilizzano tutto il tempo del processore.

Ci sono moltissimi strumenti più potenti là fuori, ma prima provane uno gratuito.Quindi, quando leggi quali altre funzionalità sono disponibili là fuori, avrai un'idea di come potrebbero aiutarti.

Questo è un tipico problema di "CPU elevata".

Esistono due tipi di problemi elevati della CPU

a) Dove il thread utilizza la CPU al 100% di un core (questo è il tuo scenario)

b) L'utilizzo della CPU è "anormalmente alto" quando eseguiamo determinate azioni.In questi casi la CPU potrebbe non essere al 100% ma sarà eccessivamente alta.In genere ciò accade quando nel codice sono presenti operazioni ad uso intensivo della CPU come l'analisi XML, la deserializzazione della serializzazione, ecc.

Il caso (a) è facile da analizzare.Quando si verificano dump del thread 5-6 della CPU al 100% in intervalli di 30 secondi.Cerca un thread che sia attivo (nello stato "eseguibile") e che si trovi all'interno dello stesso metodo (puoi dedurlo monitorando lo stack di thread).Molto probabilmente vedrai un'"attesa occupata" (vedi il codice qui sotto per un esempio)

while(true){
  if(status) break;
  // Thread.sleep(60000); // such a statement would have avoided busy wait
}

Anche il caso (b) può essere analizzato utilizzando thread dump eseguiti a intervalli uguali.Se sei fortunato sarai in grado di scoprire il codice del problema, se non riesci a identificare il codice del problema utilizzando il thread dump.È necessario ricorrere ai profiler.Nella mia esperienza, il profiler YourKit è molto buono.

Provo sempre prima con i dump dei thread.I profiler saranno solo l’ultima risorsa.Nell'80% dei casi saremo in grado di identificare utilizzando i thread dump.

Oppure utilizza i casi di test JUnit e uno strumento di copertura del codice per alcuni dei tuoi componenti comuni.Se ci sono componenti che chiamano altri componenti, li vedrai rapidamente eseguiti molte più volte.

Utilizzo Clover con i casi di test JUnit, ma per l'open source, ho sentito che EMMA è piuttosto buona.

Nel codice a thread singolo, trovo l'aggiunta di alcune istruzioni come questa:System.out.println("A:"+ System.currentTimeMillis());è più semplice ed efficace quanto usare un profiler.Potrai presto restringere la parte del codice che causa il problema.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top