?? ?? ?? ??: Java ?? ????
Java? ?? ??? ? ??? Java? ? ?? ?? ??? ??, ? ?? ??? ??? ?? ??? ???? ?? ? ??? ?? ?? ?? ?????. ? ? ?? ??? ?? ??? ??? ??? ??? String? ????. String? ?? ??? ????? ?? ?? ??? ??? ????. ???? ???? ??? ???? ? ? ??. ??? ? ????? Java? ??? ???? ?? ????? ???????.
1. ??? ???? ??? ???? ???????
?? ? "??? ???? ??? ?? ??? - ??? ??? JVM ??? ??"??? JVM ??? ??? ??? ??????. ?? ? ????? ??? ?? ?, ??? ?? ?? ?, ??? ?? ???? ? ?? ??? ?? ?? ?? ?????. ???? ??? ??? ??? ?? ?? ? ??? ????.
???? ??????? ???? ? ??? ????. ?? ????? ???? ? ?? ??? ??? ??? ???? ???, ?? ??? ????? ???? ?? ??? ???? ????. ??? ??? ????.
String str1="abc"; String str2=new String("abc");復(fù)制代碼
??? ???? ? ? ?? ??? ???? ?????? ???? Java? ?? ??? ? ???? ? ????.
1 ??? ??? ?? ???? ?????. ??? ?? ?? ?????. 2. ???? ?? String ????? ???? ? ???? ??? ?? ?? String ??? ???? ? ???? String ??? ??? ?????.
? ??? ???? ???? Java ??? ???? ???? ??? ??? ??? ??? ???? ?? ? ????. ?? ?? "??? ???? ??? ?? ????? - ??? ??? JVM ??? ??"??? HotSpot ?? ??? ??? JDK??? ??? ?? ? ??? ?? ??????. ?? ??? ??? ????.
JDK7 ???? ???? ????. ?? ?? ??? ??(?? ??)? ??? ?? ?? ?? ??? ??? ?????. JDK7??? ??? ?? ?? ??? ???? ? ???? ???? ??? ??? Java ?? ?????. ??? ?? ?? ??? ??? ?? ??? ?????.
? ??? ??? ???? ???? ??? ?? String str1=new String("abc")? ?? ?? ?????.
1. JDK6? ??? ??
?? ?? ??? ?? JDK6? ??? ??? ??? ?????.


String? ??? ??? ??? ??? String?? ?? ??? ???? String.intern()? ??? ???.
?? ???? ? ??? ?? ? ?? ?? ?? ??? ??? ???? ??? ??? ????. ?? intern() ???? ?? ??? ???????./**
* Returns a canonical representation for the string object.
* <p>
* A pool of strings, initially empty, is maintained privately by the
* class {@code String}.
* <p>
* When the intern method is invoked, if the pool already contains a
* string equal to this {@code String} object as determined by
* the {@link #equals(Object)} method, then the string from the pool is
* returned. Otherwise, this {@code String} object is added to the
* pool and a reference to this {@code String} object is returned.
* <p>
* It follows that for any two strings {@code s} and {@code t},
* {@code s.intern() == t.intern()} is {@code true}
* if and only if {@code s.equals(t)} is {@code true}.
* <p>
* All literal strings and string-valued constant expressions are
* interned. String literals are defined in section 3.10.5 of the
* <cite>The Java™ Language Specification</cite>.
*
* @return a string that has the same contents as this string, but is
* guaranteed to be from a pool of unique strings.
*/
public native String intern();復(fù)制代碼
emmmm.... ???? ???? ?????? ?? ??? ? ? ???? ??? ????. ???? ??? ????: intern ???? ??? ? ??? ?? ?? ?? String ??? ??? ???? ???? ??? ??? ?? ?? ???? ?? ??? ?? ?????. ??? ??? ? ??? ??? ??? ???? ?? ?? ???? ? ??? ?? ??? ?????.
1.一個(gè)關(guān)于intern()的簡(jiǎn)單例子
了解了intern方法的用途之后,來(lái)看一個(gè)簡(jiǎn)單的列子:
public class Test { public static void main(String[] args) { String str1 = "hello world"; String str2 = new String("hello world"); String str3=str2.intern(); System.out.println("str1 == str2:"+(str1 == str2)); System.out.println("str1 == str3:"+(str1 == str3)); } }復(fù)制代碼
上面的一段代碼會(huì)輸出什么?編譯運(yùn)行之后如下:

如果理解了intern方法就很容易解釋這個(gè)結(jié)果了,從上面截圖中可以看到,我們的運(yùn)行環(huán)境是JDK8。
String str1 = "hello world"; 這行代碼會(huì)首先在Java堆中創(chuàng)建一個(gè)對(duì)象,并將該對(duì)象的引用放入字符串常量池中,str1指向常量池中的引用。
String str2 = new String("hello world");這行代碼會(huì)通過(guò)new來(lái)實(shí)例化一個(gè)String對(duì)象,并將該對(duì)象的引用賦值給str2,然后檢測(cè)字符串常量池中是否已經(jīng)有了與“hello world”相等的對(duì)象,如果沒(méi)有,則會(huì)在堆內(nèi)存中再生成一個(gè)值為"hello world"的對(duì)象,并將其引用放入到字符串常量池中,否則,不會(huì)再去創(chuàng)建。這里,第一行代碼其實(shí)已經(jīng)在字符串常量池中保存了“hello world”字符串對(duì)象的引用,因此,第二行代碼就不會(huì)再次向常量池中添加“hello world"的引用。
String str3=str2.intern(); 這行代碼會(huì)首先去檢測(cè)字符串常量池中是否已經(jīng)包含了”hello world"的String對(duì)象,如果有則直接返回其引用。而在這里,str2.intern()其實(shí)剛好返回了第一行代碼中生成的“hello world"對(duì)象。
因此【System.out.println("str1 == str3:"+(str1 == str3));】這行代碼會(huì)輸出true.
如果切到JDK6,其打印結(jié)果與上一致,至于原因讀者可以自行分析。

2.改造例子,再看intern
上一節(jié)中我們通過(guò)一個(gè)例子認(rèn)識(shí)了intern()方法的作用,接下來(lái),我們對(duì)上述例子做一些修改:
public class Test { public static void main(String[] args) { String str1=new String("he")+new String("llo"); String str2=str1.intern(); String str3="hello"; System.out.println("str1 == str2:"+(str1 == str2)); System.out.println("str2 == str3:"+(str2 == str3)); } }復(fù)制代碼
先別急著看下方答案,思考一下在JDK7(或JDK7之后)及JDK6上會(huì)輸出什么結(jié)果?
1).JDK8的運(yùn)行結(jié)果分析
我們先來(lái)看下我們先來(lái)看下JDK8的運(yùn)行結(jié)果:

通過(guò)運(yùn)行程序發(fā)現(xiàn)輸出的兩個(gè)結(jié)果都是true,這是為什么呢?我們通過(guò)一個(gè)圖來(lái)分析:

String str1=new String("he")+new String("llo"); 這行代碼中new String("he")和new String("llo")會(huì)在堆上生成四個(gè)對(duì)象,因?yàn)榕c本例無(wú)關(guān),所以圖上沒(méi)有畫(huà)出,new String("he")+new String("llo")通過(guò)”+“號(hào)拼接后最終會(huì)生成一個(gè)"hello"對(duì)象并賦值給str1。
String str2=str1.intern(); 這行代碼會(huì)首先檢測(cè)字符串常量池,發(fā)現(xiàn)此時(shí)還沒(méi)有存在與”hello"相等的字符串對(duì)象的引用,而在檢測(cè)堆內(nèi)存時(shí)發(fā)現(xiàn)堆中已經(jīng)有了“hello"對(duì)象,遂將堆中的”hello"對(duì)象的應(yīng)用放入字符串常量池中。
String str3="hello"; 這行代碼發(fā)現(xiàn)字符串常量池中已經(jīng)存在了“hello"對(duì)象的引用,因此將str3指向了字符串常量池中的引用。
此時(shí),我們發(fā)現(xiàn)str1、str2、str3指向了堆中的同一個(gè)”hello"對(duì)象,因此,就有了上邊兩個(gè)均為true的輸出結(jié)果。
2).JDK6的運(yùn)行結(jié)果分析
我們將運(yùn)行環(huán)境切換到JDK6,來(lái)看下其輸出結(jié)果:

有點(diǎn)意思!相同的代碼在不同的JDK版本上輸出結(jié)果竟然不相等。這是怎么回事呢?我們還通過(guò)一張圖來(lái)分析:

String str1=new String("he")+new String("llo"); 這行代碼會(huì)通過(guò)new String("he")和new String("llo")會(huì)分別在Java堆與字符串常量池中各生成兩個(gè)String對(duì)象,由于與本例無(wú)關(guān),所以并沒(méi)有在圖中畫(huà)出。而new String("he")+new String("llo")通過(guò)“+”號(hào)拼接后最終會(huì)在Java堆上生成一個(gè)"hello"對(duì)象,并將其賦值給了str1。
String str2=str1.intern(); 這行代碼檢測(cè)到字符串常量池中還沒(méi)有“hello"對(duì)象,因此將堆中的”hello“對(duì)象復(fù)制到了字符串常量池,并將其賦值給str2。
String str3="hello"; 這行代碼檢測(cè)到字符串常量池中已經(jīng)有了”hello“對(duì)象,因此直接將str3指向了字符串常量池中的”hello“對(duì)象。 此時(shí)str1指向的是Java堆中的”hello“對(duì)象,而str2和str3均指向了字符串常量池中的對(duì)象。因此,有了上面的輸出結(jié)果。
通過(guò)這兩個(gè)例子,相信大家因該對(duì)String的intern()方法有了較深的認(rèn)識(shí)。那么intern()方法具體在開(kāi)發(fā)中有什么用呢?推薦大家可以看下美團(tuán)技術(shù)團(tuán)隊(duì)的一篇文章《深入解析String#intern》中舉的兩個(gè)例子。限于篇幅,本文不再舉例分析。
三、String類的結(jié)構(gòu)及特性分析
前兩節(jié)我們認(rèn)識(shí)了String的內(nèi)存分配以及它的intern()方法,這兩節(jié)內(nèi)容其實(shí)都是對(duì)String內(nèi)存的分析。到目前為止,我們還并未認(rèn)識(shí)String類的結(jié)構(gòu)以及它的一些特性。那么本節(jié)內(nèi)容我們就此來(lái)分析。先通過(guò)一段代碼來(lái)大致了解一下String類的結(jié)構(gòu)(代碼取自jdk8):
public final class String implements java.io.Serializable, Comparable<String>, CharSequence { /** The value is used for character storage. */ private final char value[]; /** Cache the hash code for the string */ private int hash; // Default to 0 // ...}復(fù)制代碼
可以看到String類實(shí)現(xiàn)了Serializable接口、Comparable接口以及CharSequence接口,意味著它可以被序列化,同時(shí)方便我們排序。另外,String類還被聲明為了final類型,這意味著String類是不能被繼承的。而在其內(nèi)部維護(hù)了一個(gè)char數(shù)組,說(shuō)明String是通過(guò)char數(shù)組來(lái)實(shí)現(xiàn)的,同時(shí)我們注意到這個(gè)char數(shù)組也被聲明為了final,這也是我們常說(shuō)的String是不可變的原因。
1.不同JDK版本之間String的差異
Java的設(shè)計(jì)團(tuán)隊(duì)一直在對(duì)String類進(jìn)行優(yōu)化,這就導(dǎo)致了不同jdk版本上String類的實(shí)現(xiàn)有些許差異,只是我們使用上并無(wú)感知。下圖列出了jdk6-jdk9中String源碼的一些變化。

可以看到在Java6之前String中維護(hù)了一個(gè)char 數(shù)組、一個(gè)偏移量 offset、一個(gè)字符數(shù)量 count以及一個(gè)哈希值 hash。 String對(duì)象是通過(guò) offset 和 count 兩個(gè)屬性來(lái)定位 char[] 數(shù)組,獲取字符串。這么做可以高效、快速地共享數(shù)組對(duì)象,同時(shí)節(jié)省內(nèi)存空間,但這種方式很有可能會(huì)導(dǎo)致內(nèi)存泄漏。
在Java7和Java8的版本中移除了 offset 和 count 兩個(gè)變量了。這樣的好處是String對(duì)象占用的內(nèi)存稍微少了些,同時(shí) String.substring 方法也不再共享 char[],從而解決了使用該方法可能導(dǎo)致的內(nèi)存泄漏問(wèn)題。
從Java9開(kāi)始,String中的char數(shù)組被byte[]數(shù)組所替代。我們知道一個(gè)char類型占用兩個(gè)字節(jié),而byte占用一個(gè)字節(jié)。因此在存儲(chǔ)單字節(jié)的String時(shí),使用char數(shù)組會(huì)比byte數(shù)組少一個(gè)字節(jié),但本質(zhì)上并無(wú)任何差別。 另外,注意到在Java9的版本中多了一個(gè)coder,它是編碼格式的標(biāo)識(shí),在計(jì)算字符串長(zhǎng)度或者調(diào)用 indexOf() 函數(shù)時(shí),需要根據(jù)這個(gè)字段,判斷如何計(jì)算字符串長(zhǎng)度。coder 屬性默認(rèn)有 0 和 1 兩個(gè)值, 0 代表Latin-1(單字節(jié)編碼),1 代表 UTF-16 編碼。如果 String判斷字符串只包含了 Latin-1,則 coder 屬性值為 0 ,反之則為 1。
2.String字符串的裁剪、拼接等操作分析
在本節(jié)內(nèi)容的開(kāi)頭我們已經(jīng)知道了字符串的不可變性。那么為什么我們還可以使用String的substring方法進(jìn)行裁剪,甚至可以直接使用”+“連接符進(jìn)行字符串的拼接呢?
(1)String的substring實(shí)現(xiàn)
關(guān)于substring的實(shí)現(xiàn),其實(shí)我們直接深入String的源碼查看即可,源碼如下:
public String substring(int beginIndex) { if (beginIndex < 0) { throw new StringIndexOutOfBoundsException(beginIndex); } int subLen = value.length - beginIndex; if (subLen < 0) { throw new StringIndexOutOfBoundsException(subLen); } return (beginIndex == 0) ? this : new String(value, beginIndex, subLen); }復(fù)制代碼
從這段代碼中可以看出,其實(shí)字符串的裁剪是通過(guò)實(shí)例化了一個(gè)新的String對(duì)象來(lái)實(shí)現(xiàn)的。所以,如果在項(xiàng)目中存在大量的字符串裁剪的代碼應(yīng)盡量避免使用String,而是使用性能更好的StringBuilder或StringBuffer來(lái)處理。
(2)String的字符串拼接實(shí)現(xiàn)
1)字符串拼接方案性能對(duì)比
關(guān)于字符串的拼接有很多實(shí)現(xiàn)方法,在這里我們舉三個(gè)例子來(lái)進(jìn)行一個(gè)性能對(duì)比,分別如下:
使用”+“操作符拼接字符串
public class Test { private static final int COUNT=50000; public static void main(String[] args) { String str=""; for(int i=0;i<COUNT;i++) { str=str+"abc"; } }復(fù)制代碼
使用String的concat()方法拼接
public class Test { private static final int COUNT=50000; public static void main(String[] args) { String str=""; for(int i=0;i<COUNT;i++) { str=str+"abc"; } }復(fù)制代碼
使用StringBuilder的append方法拼接
public class Test { private static final int COUNT=50000; public static void main(String[] args) { StringBuilder str=new StringBuilder(); for(int i=0;i<COUNT;i++) { str.append("abc"); } }復(fù)制代碼
如上代碼,通過(guò)三種方法分別進(jìn)行了50000次字符串拼接,每種方法分別運(yùn)行了20次。統(tǒng)計(jì)耗時(shí),得到以下表格:
拼接方法 | 最小用時(shí)(ms) | 最大用時(shí)(ms) | 平均用時(shí)(ms) |
---|---|---|---|
"+"操作符 | 4868 | 5146 | 4924 |
String的concat方法 | 2227 | 2456 | 2296 |
StringBuilder的append方法 | 4 | 12 | 6.6 |
從以上數(shù)據(jù)中可以很直觀的看到”+“操作符的性能是最差的,平均用時(shí)達(dá)到了4924ms。其次是String的concat方法,平均用時(shí)也在2296ms。而表現(xiàn)最為優(yōu)秀的是StringBuilder的append方法,它的平均用時(shí)竟然只有6.6ms。這也是為什么在開(kāi)發(fā)中不建議使用”+“操作符進(jìn)行字符串拼接的原因。
2)三種字符串拼接方案原理分析
”+“操作符的實(shí)現(xiàn)原理由于”+“操作符是由JVM來(lái)完成的,我么無(wú)法直接看到代碼實(shí)現(xiàn)。不過(guò)Java為我們提供了一個(gè)javap的工具,可以幫助我們將Class文件進(jìn)行一個(gè)反匯編,通過(guò)匯編指令,大致可以看出”+“操作符的實(shí)現(xiàn)原理。
public class Test { private static final int COUNT=50000; public static void main(String[] args) { for(int i=0;i<COUNT;i++) { str=str+"abc"; } }復(fù)制代碼
把上邊這段代碼編譯后,執(zhí)行javap,得到如下結(jié)果:

注意圖中的”11:“行指令處實(shí)例化了一個(gè)StringBuilder,在"19:"行處調(diào)用了StringBuilder的append方法,并在第”27:"行處調(diào)用了String的toString()方法??梢?jiàn),JVM在進(jìn)行”+“字符串拼接時(shí)也是用了StringBuilder來(lái)實(shí)現(xiàn)的,但為什么與直接使用StringBuilder的差距那么大呢?其實(shí),只要我們將上邊代碼轉(zhuǎn)換成虛擬機(jī)優(yōu)化后的代碼一看便知:
public class Test { private static final int COUNT=50000; public static void main(String[] args) { String str=""; for(int i=0;i<COUNT;i++) { str=new StringBuilder(str).append("abc").toString(); } }復(fù)制代碼
可見(jiàn),優(yōu)化后的代碼雖然也是用的StringBuilder,但是StringBuilder卻是在循環(huán)中實(shí)例化的,這就意味著循環(huán)了50000次,創(chuàng)建了50000個(gè)StringBuilder對(duì)象,并且調(diào)用了50000次toString()方法。怪不得用了這么長(zhǎng)時(shí)間?。?!
String的concat方法的實(shí)現(xiàn)原理關(guān)于concat方法可以直接到String內(nèi)部查看其源碼,如下:
public String concat(String str) { int otherLen = str.length(); if (otherLen == 0) { return this; } int len = value.length; char buf[] = Arrays.copyOf(value, len + otherLen); str.getChars(buf, len); return new String(buf, true); }復(fù)制代碼
可以看到,在concat方法中使用Arrays的copyOf進(jìn)行了一次數(shù)組拷貝,接下來(lái)又通過(guò)getChars方法再次進(jìn)行了數(shù)組拷貝,最后通過(guò)new實(shí)例化了String對(duì)象并返回。這也意味著每調(diào)用一次concat都會(huì)生成一個(gè)String對(duì)象,但相比”+“操作符卻省去了toString方法。因此,其性能要比”+“操作符好上不少。
至于StringBuilder其實(shí)也沒(méi)必要再去分析了,畢竟”+“操作符也是基于StringBuilder實(shí)現(xiàn)的,只不過(guò)拼接過(guò)程中”+“操作符創(chuàng)建了大量的對(duì)象。而StringBuilder拼接時(shí)僅僅創(chuàng)建了一個(gè)StringBuilder對(duì)象。
四、總結(jié)
本篇文章我們深入分析了String字符串的內(nèi)存分配、intern()方法,以及String類的結(jié)構(gòu)及特性。關(guān)于這塊知識(shí),網(wǎng)上的文章魚(yú)龍混雜,甚至眾說(shuō)紛紜。筆者也是參考了大量的文章并結(jié)合自己的理解來(lái)做的分析。但是,避免不了的可能會(huì)出現(xiàn)理解偏差的問(wèn)題,如果有,希望大家多多討論給予指正。 同時(shí),文章中多次提到StringBuilder,但限于文章篇幅,沒(méi)能給出關(guān)于其詳細(xì)分析。不過(guò)不用擔(dān)心,我會(huì)在下一篇文章中再做探討。 不管怎樣,相信大家看完這篇文章后一定 對(duì)String有了更加深入的認(rèn)識(shí),尤其是了解String類的一些裁剪及拼接中可能造成的性能問(wèn)題,在今后的開(kāi)發(fā)中應(yīng)該盡量避免。
? ??? ??? ???? ??? ?? ??? (1) Java? ???? ?? ??? ??? ?? ?????. ??? ??? PHP ??? ????? ?? ?? ??? ?????!

? AI ??

Undress AI Tool
??? ???? ??

Undresser.AI Undress
???? ?? ??? ??? ?? AI ?? ?

AI Clothes Remover
???? ?? ???? ??? AI ?????.

Clothoff.io
AI ? ???

Video Face Swap
??? ??? AI ?? ?? ??? ???? ?? ???? ??? ?? ????!

?? ??

??? ??

???++7.3.1
???? ?? ?? ?? ???

SublimeText3 ??? ??
??? ??, ???? ?? ????.

???? 13.0.1 ???
??? PHP ?? ?? ??

???? CS6
??? ? ?? ??

SublimeText3 Mac ??
? ??? ?? ?? ?????(SublimeText3)

settings.json ??? ??? ?? ?? ?? ?? ?? ??? ??? VSCODE ??? ??? ???? ? ?????. 1. ??? ?? ?? : Windows? C : \ Users \\ AppData \ Roaming \ Code \ User \ Settings.json, MacOS IS /users//library/applicationsupport/code/user/settings.json, linux? /home//.config/code/user/settings.json; 2. Workspace ?? ?? : .vscode/settings project root ????

JDBC ????? ???? ????? ?? ?? ?? ??? ?? ?? ??? ?? ? ?? ??? ?? ?? ?? ??? ???????. 1. ????? ????? Conn.SetAutoCommit (False)?? ??????. 2. ??? ? ????? ?? ?? SQL ??? ?????. 3. ?? ??? ??? ?? Conn.commit ()?? ???? ??? ???? ???? ?? ??? ???? Conn.Rollback ()?? ??????. ???, ? ??? ???? ????, ??? ???? ????, ?? ??? ??? ?? ??? ??? ???? ? ???????. ?? ?? ?? ???? ????? ??? ???? ?? ?? ???? ???? ??? ????? ?? ??? ??? ? ?? ???? ?? ????.

??? (DI) ISADESIGNPATTORNWHEREWHEDROUDIVESTESTESTETESTERGROWCONSTRUCTOR, 2.SPRINGFRAMEWWERTHUSENONTATIONS? ??@autowiredWithjava ?? CONCUTTATIONS LIKERWITHCONSTRUCTOR, ORFIELDINGESS.2.SPRINGFRAMEWWERTHUSENNOTATIONS

itertools.combinations? ?? ??? ???? ??? ?? ??? ???? ?? ? ?? ?? (?? ???)? ???? ? ?????. ???? ??? ????. 1. ?? ??? ??? ?? ( 'a', 'b'), ( 'a', 'c') ? ???? 2 ?? ?? ??? ?????. 2. ?? ??? ??? "ABC"? "ABD"? ?? ???? 3 ? ??? ???; 3. ? ??? ?? 1 5 = 6? ?? ?? ?? ??? ??? ?????. ?? ?? ??? ???????. ??? ??? ??? ??? ???? ??????, ??? AB? BA? ???? ???? ??, ??? ?? ??? ????.

???? ?? ?? ?? ?? ???? ?? ???? ???? ? ???? ?????. 1. @pytest.fixture ?????? ???? ???? ??????. 2. ??? ???? ???? ??? ???? ??; 3. ?? ?? ??? ?? ? ?? ??; 4. ??, ?? ?? ?? ?? ?? ??? ?? ?? ??; 5. ?? ???? Conftest.py? ???? ??? ?? ??? ???? ???? ?? ?? ? ??? ?? ??????.

java.lang.outofMemoryError : javaheapspace? ? ???? ???? ? ??, ??? ?? ? ? ??? ??? ???? ? ?? ?? ??? ?? ??? ??? ????????. 2. Metaspace ??? ??? ??? ?? ???? ?? ?? ??? ?? ?? ? ???? ????? MaxMetaspacesize? ???? ?????? ????????. 3. UnableTocreatenewnativeThread ?? ??? ??? ???? ?? ??? ?? ???? ??? ?? ???? ?? ??? ???????. 4. GCOVERHEADLIMITEXEDED? GC? ????? ???? ??? GC ??? ???? ????? ?? ?????.

?? ?? ? ?? ???? ???? ?? Java.Time ???? ???? ??????. 2. LocalDate, LocalDateTime ? LocalTime? ?? ?? ??? ??? ?????. 3. () ???? ???? ?? ??? ??? ????. 4. ???/???? ??? ???? ??? ????? ??? ??????. 5. ZonedDateTime ? Zoneid? ???? ???? ??????. 6. DateTimeFormatter? ?? ?? ? ?? ?? ?? ???; 7. ??? ?? ?? ?? ??? ????? ?? ??????. ?? Java? ?? ??? ???? ??? ??? ???? Java.Timeapi ??? ?? ??? ???????.

thejvmenablesjava? "WriteOnce, Runynywhere"??? ?? excodecodethroughfourmaincomponents : 1. theclassloadersubsystemloads, ??, ? intinitializes.classfilesusingbootsprap, extension, andapplicationclassloaders, ensuringsecureandlazyclasloa
