Prima di entrare nei dettagli del codice e della soluzione, faccio una breve introduzione al problema.
L’applicazione in oggetto è un sistema di controllo domotico relativamente semplice, infatti il compito richiesto è il coordinamento della sola parte audio e video, senza altri tipi di integrazione.
Il controllo dei sistemi audio e video è un problema che ricorre in tutti gli impianti realizzati dall’azienda in cui lavoro attualmente, quindi per accelerare i tempi ho scritto un framework in Java in modo tale che tutte le problematiche ricorrenti vengano gestite nel modo più automatico possibile.; tale framework è abbastanza complesso perchè ogni impianto è fatto ad hoc per ogni cliente e quindi si ha una grande varietà di classi in grado di risolvere i problemi tipici.

Nell’ultima installazione, sebbene i singoli compiti fossero confinati al controllo dell’audio e del video, si aveva per la prima volta un insieme piuttosto vasto di apparecchi; in altri termini la singola stanza è semplice, ma quello che è elevato è il numero delle stanze stesse.
La centrale di controllo si interfaccia con i dispositivi o tramite una delle sue porte seriali oppure tramite una connessione IP.
Al momento del test dell’impianto è stato evidente che in alcuni casi le cose non andavano come previsto: la centrale di controllo inviava effettivamente i comandi, il dispositivo rispondeva in tempi brevissimi, ma l’applicativo di controllo vedeva la risposta solo dopo un po’, a volte il ritardo era anche di alcuni secondi.

Era necessario capire il problema e trovare la soluzione.
Avevamo due indizi fondamentali: il primo erano tutti gli impianti fatti in precedenza, anche più grandi di quello in oggetto e scritti nel linguaggio di programmazione proprietario della centrale, che hanno sempre funzionato senza problemi e che le connessioni seriali non davano alcun problema di sorta.
La conclusione era abbastanza evidente: per qualche motivo c’era un problema sulla ricezione di pacchetti IP dall’applicativo Java… ma dove?
Gli indagati erano 3:

1. Il framework nella sua completezza
2. la gestione delle connessioni IP a livello applicativo
3. la JVM e il sistema operativo della centrale

Il framework nella sua completezza non sembrava il responsabile, visto che gestisce senza alcun rallentamento le connessione seriali, quindi il problema era o nelle connessioni IP a livello applicativo o in uno degli strati a cui si appoggia, ma sul campo non avevo modo di capirlo, infatti se la regola numero uno dell’ottimizzazione è

Non ottimizzare

la seconda è

Misurare, non tirare a indovinare

quindi sono tornato in ufficio e con calma mi sono messo a lavorare sulle connessioni IP a livello applicativo, che erano l’unica possibilità per me di migliorare la situazione: un rallentamento a livello di JVM o di sistema operativo infatti non sarebbero stato risolvibili da me direttamente.

L’ambiente di test che ho realizzato è stato molto semplice: due connessioni TCP/IP su socket locale che si scambiano dati secondo un protocollo banale, cioè un processo inviava dei dati all’altro che li rispediva indietro (in sostanza una delle due parti è un echo server).
Usando il profiler di Netbeans scopro che la maggior parte del tempo viene passata nella funzione di lettura dei dati da socket, questo mi ha dato due indicazioni importanti:

1. il problema probabilmente era lì: il campo di ricerca si era ridotto
2. la lettura però è bloccante, quindi è ragionevole che si passi molto tempo in quel metodo

Il metodo di lettura da socket è qualcosa di questo tipo:

public String read() throws IOException {

Il modo di procedere è stato analizzare i 4 blocchi lo compongono: ho cercato una soluzione più veloce per ogni parte confrontando i dati con quelli del caso base.
I check e la creazione della stringa in pratica non hanno impatto sulle prestazioni, così come la sostituzione del bufferedReader usato per incapsulare il socket con qualcosa di più leggero, mentre riciclando il buffer al posto di ricrearlo ad ogni invocazione le performance sono migliorate di un 40% abbondante, che è un ottimo incremento, superiore alle mie aspettative, infatti sarei stato pronto a scommettere che il collo di bottiglia fosse sulla lettura e non lì: ecco perchè è importante misurare sempre quando si ottimizza, lasciando in disparte il proprio intuito. 

Molto soddisfatto di quanto ottenuto, modifico anche il programma che sulla centrale e lo provo: con immensa sorpresa noto che l’incremento di prestazioni è qualcosa si eccezionale, oserei dire mostruoso. Giusto per dare qualche dato, sul mio pc si passa da 25 secondi a 14 per l’esecuzione di un certo numero di test, sulla centrale di controllo (con un numero di test diversi rispetto a quelli del pc, quindi i dati non sono confrontabili direttamente) da 209 secondi a 10!!! Un miglioramento di 20 volte è a dir poco incredibile.
La motivazione risiede nella JVM usata: su pc ho una Sun ufficiale ultima versione (1.6 con tutti gli aggiornamenti), mentre sulla centrale vi è una JVM non meglio definita capace di far girare J2ME (quindi 1.4).

Le conclusioni sono semplici:

1. L’ottimizzazione fa effettuata solo quando vi è una forte evidenza della sua necessità
2. Codice semplice, modulare e leggibile è da preferire sempre perchè rende più semplice l’eventuale sua ottimizzazione
3. Non fidarsi mai del proprio intuito, è decisamente meglio affidarsi ad un profiler
4. Se è stata effettuata una modifica che non ha apportato miglioramenti significativi, ritornare alla versione originale del codice se ne è stata compromessa la leggibilità
5. Prestare grandissimi attenzione se si sta effettuando sviluppo multipiattaforma o cross-piattaforma: assicurarsi sempre che i miglioramenti siano evidenti anche per la piattaforma su cui si andrà in produzione: spesso le virtual machine e i compilatori sono in grado di aumentare le prestazioni molto più di quanto si creda

La domanda sembra banale: sotto quali condizioni un oggetto a è uguale ad un oggetto b?

In termini formali l’uguaglianza è una relazione riflessiva, transitiva e simmetrica; le specifiche di Java richiedono anche che sia consistente, cioè che il risultato dell’operazione rimanga lo stesso purchè nessuna informazione usata nella comparazione venga modificata: in altri termini due oggetti il cui stato non viene modificato devono essere sempre uguali o sempre diversi.
In Java, e in molti linguaggi OO, esiste una strettissima relazione tra l’equals e l’hash code: due oggetti uguali devono avere lo stesso hash code, inoltre quest’ultimo non deve cambiare se non ci sono cambiamenti nello stato.

Oggetti immutabili non pongono particolari problemi, mentre per quelli mutabili la situazione è più complicata (altrimenti questo post non avrebbe nemmeno molto senso ).

Fondalmentalmente esistono due scuole di pensiero: la prima dice che due oggetti devono essere sempre uguali o sempre diversi per tutta la durata dell’applicazione, la seconda invece permette variazioni nel risultato.
Nelle API di Java si adotta spesso il secondo approccio, ad esempio per la classe Calendar (che comunque non rimane un esempio di design da seguire…), ma questo crea problemi tutte le volte in cui si indicizza qualcosa tramite hash code, come nelle HashMap o HashSet e in generale nei Set, tant’è che nella javadoc si trova questa frase:

Note: Great care must be exercised if mutable objects are used as set elements. The behavior of a set is not specified if the value of an object is changed in a manner that affects equals comparisons while the object is an element in the set.

Per evitare questi problemi si può seguire l’approccio opposto, cioè sostenere che se due oggetti sono uguali, allora lo sono per sempre e che se sono diversi allora lo sono per sempre. E’ possibile spingersi oltre e dire che deve valere l’uguaglianza comportamentale, cioè che due o più oggetti sono uguali allora non è possibile distinguerli richiamando in un ordine qualsiasi i loro metodi. Questo è l’approccio consigliato da Liskov.
La diretta conseguenza è piuttosto radicale: due oggetti mutabili sono uguali solo se sono lo stesso oggetto, quindi il metodo equals non deve essere ridefinito, così come il metodo hashCode.

In Refactoring Martin Fowler fa una classificazione decisamente interessante in questo senso: ci sono oggetti dei quali ci interessa il valore e oggetti di cui ci interessa l’identità. Fanno parte della prima categoria ad esempio le date e la valuta: in questo caso andrebbero implementati come oggetti immutabili con l’override di equals; appartengono alla seconda categoria ad esempio le persone dove il reale interesse è legato all’identità: istanze mutabili sono quindi legittime, ma potrebbe essere necessario introdurre una factory per garantire che l’esistenza di una singola istanza quando si richiede lo stesso oggetto in punti diversi del programma.

Inizialmente ero molto scettico riguardo a questa definizione di uguaglianza, ma poi ho iniziato a seguirla in modo metodico e devo ammettere che funziona molto bene. Non vi è una grande perdita di libertà nell’implementazione, ma se ne guadagna parecchio in chiarezza del design: ogni volta che mi trovo a creare una nuova classe mi chiedo se sono interessato al valore o all’identità, prendendo poi le decisioni del caso.