Devo preoccuparmi della "sicurezza del thread" nelle applicazioni web java

3

Ho una comprensione generale del significato di sicurezza dei thread, ma non ne so molto sui thread nel contesto di un'applicazione web Java. Sono solo curioso di sapere che devo preoccuparmi della sicurezza dei thread mentre lavoro con l'applicazione web.

Potrebbero esserci possibilità che la mia applicazione web causi dei problemi se ho scritto dei codici senza riguardo a "Sicurezza del filo"? Devo pensarci se sto usando una raccolta sicura o no?

    
posta abhijeet 28.07.2014 - 10:29
fonte

2 risposte

7

Sì, certamente lo fai :) La maggior parte (tutti?) dei contenitori web JEE eseguirà le tue classi con più thread simultanei. Inoltre, framework come Spring MVC usano istanze di classe singleton per servire tutti i thread. Ma seguendo alcune semplici linee guida manterrai il tuo codice thread-safe.

  • Non è possibile memorizzare i dati che appartengono all'utente nelle variabili membro delle classi singleton (in genere controllori e validatori). I dati dell'utente appartengono al modello, che deve essere specifico per l'utente.
  • Non è necessario preoccuparsi delle raccolte thread-safe ecc a meno che più thread possano accedervi. Questo è insolito in un'applicazione web. Ad esempio qualcosa come una collezione "whos logged in" dovrà essere thread-safe, ma non è necessario un elenco di valori personali per l'utente.
  • Le variabili locali dichiarate all'interno dei metodi non devono necessariamente essere thread-safe, poiché ad ogni richiamo del metodo viene automaticamente assegnata una nuova variabile.
  • Se il tuo framework web fornisce una funzione "sincronizza sulla sessione" (Spring MVC lo fa) , Ti suggerisco di accenderlo. Ciò significa che se l'utente preme Invio due volte in rapida successione, la prima sottomissione terminerà l'esecuzione prima della seconda inizia. Questo ti dà la possibilità di gestirlo in modo intelligente. Senza di esso c'è una possibilità piccola ma finita che due thread combatteranno sulla struttura dei dati dell'utente con risultati strani garantiti.
  • L'accesso alle strutture di dati globali deve essere progettato tenendo presenti i problemi di threading. Ad esempio una cache di valori letti da un database avrà sicuramente bisogno di essere thread-safe.
  • Evita l'uso di file per l'archiviazione intermedia. Le scritture multi-thread su un file sono difficili da sincronizzare e quasi impossibile se più JVM scrivono sullo stesso file (come può succedere in "server farm" o installazioni in cluster). Se hai questa necessità, usa un database - il controllo delle transazioni è molto più semplice.
  • Un caso particolare si presenta quando più utenti possono aggiornare gli stessi dati. Ma questo non è esattamente un problema di threading: prova Google per "transazioni a lungo termine". È un argomento importante.

Quindi sì, devi essere informato sui thread, ma in pratica non è un grosso problema.

    
risposta data 28.07.2014 - 11:34
fonte
1

Sì.

Ogni richiesta HTTP (elaborata da Servlet, JSP, qualunque sia) viene elaborata da un thread diverso, quindi puoi aspettarti il set completo di condizioni di runtime.

Ad esempio, se si mantiene un elenco di elementi e si scorre su di esso, se allo stesso tempo un altro servlet aggiunge o rimuove un elemento da elencare, è possibile ottenere un ConcurrentModificationException

È possibile ridurlo usando solo oggetti istanziati nel servlet o EJB stateless. Ma anche con questo, si potrebbero avere problemi di incoerenza dei dati se non si progettano correttamente le transazioni DB.

    
risposta data 28.07.2014 - 11:28
fonte

Leggi altre domande sui tag