最新回答 / 實(shí)時(shí)編程
HashMap。本身就不是線程安全的，所以 你這個(gè)寫法 我暫時(shí)不確定 是不是能正確的運(yùn)行?但是既然不是線程安全的? 所以 我覺得 不可以這樣寫如果你加個(gè)鎖 確實(shí)可以 變成安全的 操作但是就會(huì) 變成多線程 競(jìng)爭(zhēng)鎖? ?非常消耗性能雖然實(shí)現(xiàn)了 類似功能 但是性能 太低?所以JDK 不會(huì)這樣設(shè)計(jì)
2020-05-07
最贊回答 / qq_Forever淺唱此生_0
小數(shù)值取數(shù)組是java做的緩存和引用沒關(guān)系，實(shí)際沒法用Integer做引用是因?yàn)镮nteger的值是final的，和String一樣，創(chuàng)建后沒辦法改變自身的值，計(jì)算后返回的都是一個(gè)新的Integer/String
2020-03-24
最新回答 / TimAndy
golang 雖然不是線程模型, 但是有協(xié)程. 可以把協(xié)程理解成其他語(yǔ)言的輕量級(jí)線程.ThreadLocal for golang 無(wú)內(nèi)存泄露, 無(wú)競(jìng)爭(zhēng),高性能, 不修改golang源碼.支持 go1.18 泛型, 支持 386, amd64, arm, arm64 平臺(tái).支持 go1.13-1.18 版本, 在 linux,windows,mac 上均測(cè)試通過(guò).項(xiàng)目地址 https://github.com/timandy/routine
2020-03-15
已采納回答 / weixin_慕桂英0137301
每個(gè)線程中，計(jì)算的都是本身進(jìn)行了add的和。因此，最后把所有的線程中的值取出，求和。就是最后的總和。
2020-03-06
最新回答 / 慕碼人118462
檢查引入的包是不是正確。檢查有沒有在idea中添加插件idea中需要設(shè)置開啟自動(dòng)開啟注解另外，你的curl read 數(shù)據(jù)不正確 可能多線程并非造成的，不一定跟@Data注解有關(guān)系
2020-03-03
最贊回答 / weixin_慕桂英0137301
因?yàn)槌绦蜃罱K是給計(jì)算機(jī)去執(zhí)行的。但是，更多的時(shí)候，是讓開發(fā)者能夠看懂代碼，方便迭代開發(fā)。
2020-03-01
最贊回答 / qq_Forever淺唱此生_0
這個(gè)HashSet和HashMap的多線程調(diào)用時(shí)是一樣的風(fēng)險(xiǎn)，在擴(kuò)容時(shí)有可能導(dǎo)致死循環(huán)，所以要用同步的容器或者同步代碼塊去調(diào)用“添加”的方法
2020-02-14
講師回答 / 求老仙
秋田君說(shuō)的也很不錯(cuò)， 我這里補(bǔ)充下， Map<Thread, T>這種結(jié)構(gòu)，hash表沖突會(huì)很嚴(yán)重，舉個(gè)例子。map.put(thread1, 100);map.put(thread1, 200);map.put(thread1, 300);你發(fā)現(xiàn)沒有，一個(gè)map put了三個(gè)值，那取值的時(shí)候， 怎么辦呢？
2020-02-10
已采納回答 / 求老仙
鎖發(fā)生在寄存器里是很快的，鎖發(fā)生在內(nèi)存里要看（如果發(fā)生在CPU的L1 cache上，就很快），如果發(fā)生在L2,L3或者內(nèi)存里就慢很多；鎖如果發(fā)生在IO上（比如讀硬盤就非常慢）。所以縮小范圍，要看縮小了什么，如果縮小了I/O，那就非常有必要了。 我用Sleep(I/O)，所謂I/O就是觸發(fā)中斷的東西，來(lái)替代真實(shí)的I/O場(chǎng)景（比如讀數(shù)據(jù)庫(kù)，讀redis等）。寄存器速度約等于(l1)，< l2, < l3? <<<<< 內(nèi)存（這里大概有幾十倍到百倍速度差距了） <...
2020-02-07
最贊回答 / Eri1c
initialValue起初始化作用只運(yùn)行一次，每個(gè)Thread對(duì)應(yīng)的Val對(duì)象的初始值確實(shí)都設(shè)為了0，沒問題
2020-02-04