Senza i distruttori simili a C ++, come possiamo restituire le risorse che non sono gestite da Garbage Collector in Java? [duplicare]

Question

Senza i distruttori simili a C ++, come possiamo restituire le risorse che non sono gestite da Garbage Collector in Java? [duplicare]

#1 da (4 voti)
#2 da (1 voti)

1

Sono in cerca di lavoro. E nel mio CV ho inserito una lista di abilità come:

 Skills: C/C++/Java/...

La domanda più comune che ho ricevuto è: "hem, dal momento che hai familiarità con C ++ e Java, puoi dire alcune somiglianze o differenze tra le due lingue."

E non so come rispondere, ciò che ho detto è fondamentalmente alcuni dettagli del livello di linguaggio come se avessero alcune parole chiave diverse come Interface , abstract e così via. Voglio vedere un confronto ad alto livello come la differenza in generics , garbage collector e così via.

Almeno voglio andare in profondità in un lato, cioè nella gestione delle risorse. Java non ha una durata per un oggetto, questo è gestito da garbage collector , e in C ++ devi gestire attentamente la tua risorsa specialmente per heap . In C ++ possiamo ridurre notevolmente la perdita di memoria introducendo RAII , usando object per gestire la memoria heap, e lo stesso vale per le altre risorse come connection , lock e così via. Non sono sicuro di cosa fare in Java, perché il garbage collector può essere solo un utile strumento per la gestione della memoria heap (AFAIK).

Domanda : come possiamo gestire altre risorse in una situazione in cui non abbiamo un distruttore per eseguire tutte queste operazioni automaticamente? Dobbiamo garantire manualmente che le risorse vengano restituite nel posto giusto. E come?

java c++ interview

posta zoujyjs 22.08.2013 - 13:39

fonte

2 risposte

Leggi altre domande sui tag java c++ interview

Come calcolare il runtime nel caso peggiore di questo algoritmo di ricerca L'approccio sicuro raccomandato per la conferma di un URL è chiamato da un utente legittimo

score 4 · Answer 1

Java 7 ha try-with-resources per gestire risorse non di memoria. Puoi implementare java.lang.AutoCloseable per usarlo con i tuoi oggetti. RAII non era un intento progettuale originale per i distruttori, è stato "scoperto" più tardi e è entrato in voga solo alla fine degli anni '90, all'inizio degli anni 2000, dopo la creazione di Java. Ecco perché Java 1-6 non ha avuto alcun costrutto simile a RAII.

score 1 · Answer 2

In realtà la domanda ha un senso, perché tutte e tre le lingue sono in qualche modo rafforzate da una stessa storia complessiva, dalle macchine VonNeuman a C come "assemblatore di alto livello", all'esigenza di industrializzare la riutilizzabilità del codice e l'introduzione del idea di "oggetto".

In C questo è solo "funzione e dati e tipi opachi". Dopo una formalizzazione di metodologie orientate agli oggetti, C ++ ha aggiunto a C l'idea di sovraccarico della funzione e di polimorfismo basato sul runtime, con l'inconveniente di garantire la durata dell'oggetto tra le funzioni e le conseguenze della gestione a vita dell'oggetto.

Java arriva subito dopo, abbracciando il paradigma OOP e progettato attorno ad esso e attorno all'idea di "indipendenza dalla piattaforma" (creando così la piattaforma n + 1: la macchina java). Limitando tutti gli oggetti a essere dinamici, ha risolto il problema del puntatore C ++, introducendo la garbage collection e unificando il puntatore e l'oggetto in una sintassi comune (la notazione).

Allo stesso modo C ++ si è evoluto verso un linguaggio più generalizzato, non restringendo in OOP, ma introducendo modelli e lambda, aprendo quella strada verso altri paradigmi di programmazione (come programmazione generica e programmazione funzionale) e metodologie di gestione delle risorse (come RAII, conteggio dei riferimenti e simili) incorporando i problemi di gestione della memoria nella libreria e nelle classi definite appositamente.

Per quello che oggi interessa, Java gorws dove il controllo delle risorse non è "il problema", ma dove avere una grande base di codice OOP multiplatfom è semplice. Il C ++ è più apprezzato laddove il controllo delle risorse e l'ottimizzazione elevata sono un must (un compilatore può hackerare il set di istruzioni asembler di una macchina, Java deve rimanere a un livello di macchina Java, interrompendo così il processo di ottimizzazione in due parti distinte) e dove algoritmo e hardware sono necessari per cooperare meglio.

Per rispondere alla domanda finale, in assenza di distruzione deterministica, la gestione delle risorse deterministiche deve essere gestita esplicitamente con metodi di finalizzazione (come "on_final" o simili) eventualmente esposti da interfacce (come "finalizzabili") per essere eventualli incatenati in raccolta, da chiamare in modo esplicito, se del caso.