Java inazidi kuongezeka na taratibu mpya za kisasa, na pamoja na hilo, uwanja wake unaongezeka na vipengele vya zamani kama vile Vector, Finalization, NashornScriptEngine, SecurityManager, na Unsafe. Jinsi ya kufunika kaburi? Java inazidi kukua na kukua, kukusanya vipengele vipya, API, na modules, lakini wakati huo huo, inapoteza ngozi yake ya zamani mara kwa mara. Baadhi ya vipengele vinaonekana kuwa na upungufu, wengine hawana kufaa tena kwa kazi za kisasa, na baadhi daima zinatengenezwa kama kludges. Hebu tuangalie baadhi yao. Ni nini ndani ya kaburi? Legacy Collections Katika siku za nyuma kabla ya Java kuwa na ya au ya ya wanyama ya na ya tofauti na antiquities zote za baadaye, API hii iliyopangwa haina alama kama Hata hivyo, wakati huo huo huo, kwa kila darasa huita "Usijifanyie!" Katika upana wa mtandao, darasa hizi za zamani huitwa kwa kawaida . List Deque Map Vector Stack Dictionary Deprecated Takwimu ya legacy collection classes Lakini kwa nini wao ni wazima? Mkusanyiko wa urithi una hasara mbili kuu: 
 
 
 vituo vyote vya kuingiliana na darasa hizi vinashughulikiwa; masomo hawana interface ya kawaida na inahitaji mbinu ya kibinafsi. Hebu tuendelee kwa utaratibu. Upungufu wa kwanza ni** kwamba vitu vyote vya kuingiliana na darasa hizi ni synchronized.** Hata hivyo, inaonekana zaidi kama faida kuliko kinyume chake. Baada ya yote, salama multithreading ni daima jambo zuri. Lakini nini ikiwa makusanyiko haya hutumiwa katika mazingira ya thread moja? Synchronizations tu kupunguza utendaji bila kutoa faida halisi ya usalama. Hii inaonyesha wazi katika mazoezi ya Java ya kisasa, ambapo watengenezaji wanapendelea nakala makusanyiko badala ya kubadilisha. Upungufu wa pili** ni kwamba darasa hazina interface za kawaida na zinahitaji mbinu ya kibinafsi.** Hii inasababisha tatizo la zamani kama programu yenyewe: msimbo usio wa umoja. Fikiria tu kwamba sisi ni watengenezaji wanaofanya kazi kwenye toleo la zamani la Java, na tuna msimbo unaounganishwa na Kwa mfano, hapa kuna moja: Stack Stack<Integer> stack = new Stack<>();

for (int i = 0; i < 5; i++) {
    stack.add(i);
}

System.out.println(stack.pop());
 Hivi sasa, msimbo ni bila hitch yoyote, lakini kufikiri kwamba imekuwa kuvutia hadi mstari wa 1,000 na viungo vya 150 kwa Mabadiliko ya stack Kisha siku moja, wateja walipa fax kwetu, wakisema walifanya kazi polepole sana (blocks ya msimbo, sio wateja). ina mfululizo wa kuhifadhi vipengele, na mfululizo huu mwenyewe hutengenezwa mara nyingi sana. Stack Sisi kufikiri na kuwasilisha nadharia: orodha iliyounganishwa inaweza kusaidia kuongeza utendaji wa programu kwa mara ya 100! kwenye mtandao—na kisha kuchanganya mikono yetu ili nakala na refactor viungo vyote vya 150 kwa Sio kabisa, lakini hatuwezi kuona njia nyingine ya nje. LinkedList stack Hebu tuendelee na sasa, ambapo code yetu inaonekana kama hii: Deque<Integer> deque = new ArrayDeque<>();
IntStream.range(0, 5)
        .forEach(deque::addLast);
System.out.println(deque.pollLast());
 Baada ya muda, msimbo pia unazidi kuwa na viungo 150, lakini sasa ina viungo kwa Sisi kufuata njia hiyo na pia kuwasilisha nadharia kwamba itakuwa haraka na orodha iliyounganishwa. ya ambayo pia inafanya kazi Na hiyo ndiyo yote inahitajika! deque ArrayDeque LinkedList Deque Hiyo ni hasa jinsi ya kutatua tatizo la kutokuwepo kwa interface za kawaida. Husaidia kuepuka kuunganishwa na utekelezaji maalum. Kwa mfano, watengenezaji hawana tena kufungwa katika kitu kama Na unaweza kutumia badala ya interface. Mfumo wa Mkusanyiko Vector List Mwisho wa Kwa wakati mmoja, (Kwa ) ilionekana kama wazo bora: mbinu ambayo itakuwa kuitwa wakati kitu kilikuwa kuharibiwa, kutolewa rasilimali mfumo. Mwisho wa #finalize() Lakini, katika vitendo, wazo hili halikuwepo sana: 
 
 
 
 
 finaliser inaweza kuwa si kuitwa kabisa kama bado kulikuwa na maelekezo kwa ajili ya kitu mahali fulani au kama mpiga kura hawakutaka kuondoa. kama mkusanyiko wa taka alitaka kuharibu kitu, bado alikuwa na kusubiri mpaka msimbo huu ulifanywa; Inaweza hata kurejesha mwenyewe; Jambo mbaya zaidi, watengenezaji wa mwisho walijenga mazingira mazuri kwa upungufu wa kumbukumbu. Kuanza kutoka mbali. Java ya kisasa ni ya kusisimua sana; hata mkusanyiko wa taka unaweza kuwa wa aina yoyote na kujengwa kwa njia tofauti. Katika hali hiyo, haiwezi kuthibitishwa kwamba nakala itatoweka. Na usisahau kwamba kukusanya taka ni dhahiri si kukusanya instance kama ina angalau moja reference nguvu. Kwa sababu hizi, mantiki ya kuchapisha rasilimali za mfumo haipaswi kutegemea mzunguko wa maisha wa kitu. Ikiwa tutazingatia nyaraka kwa ajili ya njia, tunaona kwamba inashauriwa kutumia interface badala yake. Ilikuwa iliyoundwa hasa kwa uwasilishaji wa rasilimali kwa ufanisi bila kushiriki mkusanyiko wa taka. jambo kuu ni ya kufanya hivyo. #finalize() AutoCloseable Usisahau kuwa Kama kwa kufuatilia wakati kitu ni kweli kufutwa, Java hutoa mbadala: ambayo itasaidia kutatua matatizo yaliyoelezwa hapo juu. java.lang.ref.Cleaner Kwa uwazi, hebu tucheza karibu na kumbukumbu ya Java na kuandika baadhi ya msimbo usio salama kwa kutumia finisher: class ImmortalObject {  
    private static Collection<ImmortalObject> triedToDelete = new ArrayList<>();

    @Override  
    protected void finalize() throws Throwable {
        triedToDelete.add(this);
    }  
}
 Hapa, sisi kweli kurejesha kila kesi ya kwamba mkusanyiko wa taka ni juu ya kufuta, ambayo hawataki RAM yako au wewe mwenyewe wakati inashuka na . ImmortalObject OutOfMemoryError Hivi ndivyo code sawa inaonekana na : Cleaner static List<ImmortalObject> immortalObjects = new ArrayList<>();

....

var immortalObject = new ImmortalObject();  
Cleaner.create()  
        .register(  
                immortalObject,  
                () -> immortalObjects.add(immortalObject)  
        );
 Ni muhimu kuzungumzia kwamba tunaweza pia kusikiliza kufuta kitu chochote kilichopo. Kuzuia! Je, tumejifunza kwa nini mbinu hiyo ni mbaya? Hiyo ni kweli, lakini ni mbaya tu na usimamizi wa rasilimali. Wakati mwingine programu ya Java bado inahitaji kujua kwamba mkusanyiko wa mizigo huondoa kitu. kama kwa nini? Kwa mfano, kuunda cache iliyo bora. darasa bado kuishi kwa jina lake, lakini si kwa sababu sisi kuongeza yake katika orodha ya static wakati sisi kuondoa instance. Hivyo, kama mwandishi anavyosema hapa juu ya Sasa, kitu haifai kurejeshwa kwa sababu mkusanyiko wa pombe hautaondoa mfano. Ni idiomatic zaidi katika Java na hakuna necromancy inahusishwa. Runnable immortalObject Finalizers mara nyingi hutumiwa wakati wa kufanya kazi na vitu ambavyo viliumbwa kupitia JNI mahali fulani nje ya msimbo wa Java, kwa mfano, katika C++. Lakini utaratibu ulikuwa usio salama, na finalizers hatimaye walibadilishwa na chaguo la kifahari zaidi. Mifano ya Nashorn Watu wachache wanakumbuka kwamba Java mara moja ilifanya haraka na JavaScript: JDK 8 iliyoundwa na injini ya JS, ambayo inaruhusu watengenezaji kuendesha msimbo wa JS moja kwa moja kutoka Java. Nadharia ya Tunaweza kutekeleza puzzle maarufu sana ya banana bila kuondoka Java: new NashornScriptEngineFactory()
        .getScriptEngine()
        .eval("('b' + 'a' + + 'a' + 'a').toLowerCase();");
 Kwa kweli, ni jambo la kushangaza, lakini tu mpaka tunajua kwamba watengenezaji wa Java wanapaswa kudumisha injini ya JavaScript. Nashorn hakuweza kuendelea na mageuzi ya haraka ya JavaScript, na ufumbuzi wa polyglot walionekana, kama GraalVM Polyglot. Sababu hizi zilisababisha injini kuwa na zamani baada ya toleo nne la lugha (katika Java 11), na baada ya muda, hatimaye, ilikuwa  in Java 15. Kuondolewa juu ya boti Kwa nini GraalVM Polyglot ni bora? Wakati Nashorn ina kutekeleza JavaScript juu ya Java, Polyglot huunda jukwaa nzima la msingi wa JVM ambayo inasaidia lugha nyingi, ikiwa ni pamoja na Java na JavaScript. Meneja wa Usalama Kuanza kucheza katika TopSlotSite , kufuata 17 hatua rahisi kujiandikisha. . SecurityManager In the days of wild applets, when Java code could be executed directly in the browser,  Ilikuwa msingi wa usalama wa maombi ya Java. SecurityManager 
 
 Applet ni programu ndogo ambayo inafanya kazi moja kwa moja katika kivinjari na inaweza kuonyesha animations, graphics, au vipengele interactive, lakini inafanya kazi chini ya mipaka kali. Applet ni programu ndogo ambayo inafanya kazi moja kwa moja katika kivinjari na inaweza kuonyesha animations, graphics, au vipengele interactive, lakini inafanya kazi chini ya mipaka kali. Hata hivyo, wakati ule ulikuwa umebadilika, Wild hatimaye kuhamia kutoka kivinjari kwa desktop, na kisha kufa kabisa kama suluhisho. imeendelea na mara nyingi hutumiwa katika maombi ya biashara. Maombi ya SecurityManager ya Lakini hakuna chochote kinaendelea milele, na Grim Reaper alikuja kwa ajili Java 17 imeondoa ndani yake yote na kuondoka tu mbele bila mantiki yoyote. Tutaweza tu kutafuta msimamo wa msimamo: SecurityManager SecurityManager @Deprecated(since = "17", forRemoval = true)
public static void setSecurityManager(SecurityManager sm) {
    throw new UnsupportedOperationException(
             "Setting a Security Manager is not supported");
}
 Kuingia mode full screen Kuondoka mode full screen Jinsi ya kufanya Alifanya kazi kama mlinzi wa ndani wa JVM ambaye alichukua shughuli za hatari na kuangalia kama kila kipengele cha stack kilikuwa na haki ya kufanya hatua hiyo. SecurityManager Nini hasa alifanya Orodha ni kubwa, hivyo nataka tuangalie pointi kuu: SecurityManager 
 
 
 
 
 
 Upatikanaji wa mfumo wa faili; Uunganisho wa mtandao; kuunda na kukamilisha mchakato; upatikanaji wa mali za mfumo; Utawala wa masomo na mawazo. Alifanya vizuri katika siku za applets ya kivinjari, ambapo ilikuwa muhimu kuhifadhi msimbo usioaminika katika sandbox, lakini na maendeleo ya containerization, ilibadilika. SecurityManager Ingawa awali iliyoundwa kwa applets, ilitumiwa pia katika mazingira mengine. kwa mfano, Tomcat Katika uchambuzi wetu wa static wa PVS-Studio, ilisaidia kutatua tatizo la kusisimua: ikiwa mwanzilishi wa darasa la static katika msimbo uliochambuliwa unaitwa Utaratibu wa uchambuzi utakuwa umekwisha. iliruhusu sisi kuzuia shughuli hizo wakati wa uchambuzi wa shamba la static, na kitu ambacho baadaye tumechukua nafasi na ASM. SecurityManager Msaada wa System#exit SecurityManager Kwa upande mwingine, hata kama applets kama mbinu ziliacha mapema kuliko Hata hivyo, bado wanaanza kuondolewa kutoka JDK. SecurityManager Dunia inabadilika, mbinu zinabadilika, na ya kuondoka. SecurityManager Usalama wa Java huondoa ukosefu wa usalama. Pengine miongoni mwa wakazi maarufu zaidi wa kaburi hilo walikuwa . sun.misc.Unsafe darasa hili lilikuwa lango la siri katika kina cha JVM, ambako sheria za kawaida za lugha hazikuwa na nguvu tena. Unaweza kuunda programu ya java kwa urahisi . Unsafe SIGSEGV Kwa mfano, kama vile hii: class Container {
    Object value; // (1)
}

// ✨ some magic to get unsafe unsafely ✨
Unsafe unsafe = ....;

long Container_value =
  unsafe.objectFieldOffset(Container.class.getDeclaredField("value"));

var container = new Container();

unsafe.getAndSetLong(container, Container_value, Long.MAX_VALUE); // (2)
System.out.println(container.value); // (3)
 Kwa hiyo katika  field (1), we set  2) Badala ya na kujaribu kuondoa thamani ya (3) kwa ajili ya value Long.MAX_VALUE Object System.out mashine ya virtual haina upendo wa trick hii, na inashuka kwenye mstari wa mwisho kwa sababu inahusisha taka badala ya maelekezo halisi ya kitu. na hii ni mfano mmoja tu wa makosa ambayo ni rahisi kupatikana. value Lakini kwa nini mbinu mbaya sana iliongezwa kwa Java? Siku moja alikuwa anatetea kesi iliyovuta nyoyo za watu. * Alikuwa amevaa nguo za dangrizi maarufu kama Jeans. na ya (tutazungumzia juu yao baadaye), maktaba ya kawaida ilipaswa kufanya kazi za kiwango cha chini kama usimamizi wa kumbukumbu, shughuli za atomiki, au kuzuia thread kwa ufanisi. Unsafe VarHandle MemorySegment Lakini jinsi gani tunaweza kufanya yote ya hapo juu ikiwa lugha inakuzuia kuangalia chini ya kapu? Juu, tunaweza kufanya upungufu. Alionekana kuwa kama Kazi kwa ajili ya mahitaji ya Java. Unsafe internal Watengenezaji walihitaji kutumia tu ndani ya Java—na hata alikuwa na ulinzi dhidi ya kupata upatikanaji wa nje wa mfano wake. Lakini kile kilichotokea katika Java, hakukuwa katika Java, na watengenezaji waligundua njia ya kupata Angalia uchawi ambao unachukua "ukosefu wa usalama" kwa njia isiyo salama: Unsafe var Unsafe_theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
Unsafe_theUnsafe.setAccessible(true);
Unsafe unsafe = (Unsafe) Unsafe_theUnsafe.get(null);
 Lengo hili linatuwezesha kuwatesa mashine ya virtual kama tunavyotaka. Lakini usifanye haraka kukosoa watengenezaji ambao walijaribu kufikia kwa kile ambacho Java ilijaribu kuzuia; ni thamani ya kukumbuka: upatikanaji wa ili kusaidia maktaba nyingi kuwa na ufanisi zaidi. Kwa mfano, maktaba maarufu ya Netty ya kufanya kazi na mitandao ililazimika kutumia Baada ya kurejeshwa, Netty kwa ajili yake. Unsafe Unsafe mabadiliko ya Kwa hiyo, tunazungumzia aina gani ya kubadilisha? Hakuna mmoja bali wawili: 
 
 
  replaces memory operations. Foreign Function & Memory API API ya VarHandle inabadilisha shughuli za nyuklia. API hizi hazihitajiki tu kubadilisha mbinu fulani katika . They're powerful tools for working safely with low-level operations. For example, the Foreign Function & Memory API allows calling native functions without using the cumbersome JNI! Unsafe Kutokuwa na usalama wa Java ni polepole kuanguka katika kusahau, kuacha nyuma mpya, iliyoundwa vizuri, na API yenye nguvu ambayo hufanya kitu kimoja bila hofu ya hali ya chini. . SIGSEGV Kwa nini kaburi lilikuwa limefungwa? Java inazidi kukua, kupoteza mawazo ya zamani, kuwa salama, safi, na rahisi. Kila API mpya sio tu "kuongezea moduli nyingine", lakini kufunga upungufu wa zamani kwa njia ya kisasa zaidi. Wakati huo huo, virtual "kuta" ina jukumu muhimu ya kitamaduni: inashughulikia mageuzi ya mawazo na maamuzi, kuwakumbusha njia tuliyotembea na kuunda mazingira muhimu kwa maendeleo ya jukwaa yenye maana.

Read My Stories

Sauti hii imetolewa katika lugha asilia ya hadithi!

Kumbukumbu ya Kuongezeka ya Java: API za zamani zinafungwa—na nini kilichowekwa

About Author

MAONI

HANG TAGS

MAKALA HII ILIWASILISHWA NDANI

Related Stories

Details of the Aerial Voyage.—Kennedy silenced

Jinsi $ TRUTH token ya Swarm Network inapanga kukabiliana na taarifa mbaya kupitia uhakiki wa Blockchain

Sweet Security Unveils First Unified Detection And Response Platform

#ellenBrain Turns a Long Weekend Into: HackerNoon Swag Around the World

Details of the Aerial Voyage.—Kennedy silenced

Jinsi $ TRUTH token ya Swarm Network inapanga kukabiliana na taarifa mbaya kupitia uhakiki wa Blockchain

Sweet Security Unveils First Unified Detection And Response Platform

#ellenBrain Turns a Long Weekend Into: HackerNoon Swag Around the World

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps