盧偉冰長(zhǎng)文解析K60至尊版 對(duì)Redmi有著里程碑式的意義
在今天的Redmi后性能時(shí)代戰(zhàn)略發(fā)布會(huì)結(jié)束之后，Redmi總經(jīng)理盧偉冰又帶來(lái)了一篇長(zhǎng)文，詳解了為什么 Redmi 要開(kāi)啟后性能時(shí)代？為什么選擇和 MediaTek、Pixelworks 深度合作？以及后性
小伙伴好哇，我是Tom哥。
今天分享一個(gè)寫代碼時(shí)遇到的詭異問(wèn)題，如何排查解決的。
從事互聯(lián)網(wǎng)的人都懂，一般遇到問(wèn)題時(shí)，首先會(huì)想用谷歌、百度等搜索引擎，看看前輩們是如何解決的。
但有些問(wèn)題比較抽象，不知道如何來(lái)描述，怎么辦？或者勉強(qiáng)描述清楚了，搜出來(lái)的答案也很難滿足要求，整個(gè)過(guò)程猶如大海撈針。最后求助 ChatGPT 瞬間解決，給大家分享下解決思路。
正在開(kāi)發(fā)一個(gè)項(xiàng)目，倉(cāng)儲(chǔ)層有一個(gè)接口類（IProductReadRepository），其中一個(gè)方法的入?yún)⑹褂昧?Java 泛型，具體如下：
List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);在上層的領(lǐng)域服務(wù)中，有一處調(diào)用這個(gè)方法的代碼，具體如下：
ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder() .bizCode(BusinessCodeEnum.SMART.getCode()) .bizScene(BusinessSceneEnum.RETAIL.getCode()) .storeId(multiPackageVO.getStoreId()) .bizParams(spuIds) .build();List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);if (CollectionUtils.isEmpty(productSummaryVOS)) { bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST); return bizResult;}其中，List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper); 這行代碼非常詭異
返回的結(jié)果List<ProductSummaryVO>并不匹配，但在IDEA中卻沒(méi)有報(bào)錯(cuò)，這讓我們感到非常困擾。
這是怎么回事？
當(dāng)時(shí)懷疑是錯(cuò)覺(jué)，仔細(xì)對(duì)比了兩個(gè)方法，確實(shí)是對(duì)的。
又懷疑是 IDEA 的緩存干擾導(dǎo)致，所以將工程重新 build 了一次還是不行！
接下來(lái)，能想到的各種招數(shù)都招呼上，比如：
最后，使出絕招，將本地的工程代碼全部刪除，然后重新從 git 上拉取最新代碼，編譯，導(dǎo)入到 IDEA 工程。
但，但，但，問(wèn)題依然存在，真讓人崩潰。
難道是 IDEA 中的錯(cuò)誤檢查失效了，于是人為制造了一些錯(cuò)誤，發(fā)現(xiàn) IDEA 也都能識(shí)別出來(lái)。
實(shí)在沒(méi)招了。。。。。。。
最后，還是問(wèn)下 ChatGPT 吧
首先，先把問(wèn)題描述清楚，ChatGPT 特懂人情世故，你跟他講清楚問(wèn)題，他也會(huì)給你一個(gè)清楚的答案。
有一個(gè)接口內(nèi)的方法定義如下： List<SpuVO> batchQuerySpuBySpuIdsFromDB(ProductQueryWrapper<List<Long>> req);使用下面的代碼來(lái)調(diào)用 batchQuerySpuBySpuIdsFromDB，返回的 List<SpuVO> 結(jié)果并不匹配，但在 IDEA 中沒(méi)有報(bào)錯(cuò)，是什么原因？ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder() .bizCode(BusinessCodeEnum.SMART.getCode()) .bizScene(BusinessSceneEnum.RETAIL.getCode()) .storeId(multiPackageVO.getStoreId()) .bizParams(spuIds) .build();List<ProductSummaryVO> productSummaryVOS = productReadRepository.batchQuerySpuBySpuIdsFromDB(productQueryWrapper);if (CollectionUtils.isEmpty(productSummaryVOS)) { bizResult.error(BizErrorCode.MULTI_PACKAGE_PRODUCT_NOT_EXIST); return bizResult;}
ChatGPT 很快就給出了答案。
問(wèn)題可能出在泛型擦除和編譯時(shí)類型檢查上。由于Java泛型的擦除機(jī)制，在運(yùn)行時(shí)無(wú)法獲取泛型的實(shí)際類型，這可能導(dǎo)致類型不匹配的問(wèn)題。
那我們就按照它的思路來(lái)，將這行代碼 ProductQueryWrapper productQueryWrapper = ProductQueryWrapper.builder()
修改為 ProductQueryWrapper<List<Long>> productQueryWrapper = ProductQueryWrapper.<List<Long>>builder()
在構(gòu)建 ProductQueryWrapper 對(duì)象時(shí)， 指定泛型參數(shù)的具體類型，以便在運(yùn)行時(shí)能夠正確地識(shí)別參數(shù)類型。
然后，問(wèn)題真的解決了。
如下圖所示，第二處紅框位置的代碼開(kāi)始報(bào)錯(cuò)。因?yàn)榻涌诘囊?guī)范（返回結(jié)果）調(diào)整了，此處確實(shí)應(yīng)該報(bào)錯(cuò)提示。
后面，我們根據(jù)錯(cuò)誤提示，將 ProductSummaryVO 類替換成 SpuVO 類。
最終，不但編譯不報(bào)錯(cuò)，單元測(cè)試也能跑通。問(wèn)題完美解決。
為何在 IDEA 中沒(méi)有直接報(bào)錯(cuò)呢？這里牽扯到Java泛型的類型推斷機(jī)制。
上述代碼中，雖然使用了原始類型 ProductQueryWrapper ，但沒(méi)有指定具體的泛型類型。
Java 7 及以后的版本引入了菱形操作符（Diamond Operator），允許在創(chuàng)建對(duì)象時(shí)不再重復(fù)指定泛型類型，而是通過(guò)上下文進(jìn)行類型推斷。
這就意味著在你的代碼中，雖然沒(méi)有明確指定泛型類型，但由于在 ProductQueryWrapper.builder() 上下文中，編譯器會(huì)嘗試根據(jù)調(diào)用方的期望類型來(lái)推斷泛型參數(shù)。
這種類型推斷機(jī)制使得在 IDEA 開(kāi)發(fā)工具不會(huì)直接報(bào)錯(cuò)，也就出現(xiàn)了上文說(shuō)到的那個(gè)問(wèn)題。
今天的分享就到這里，我們下回再見(jiàn)。
本文鏈接：http://www.tebozhan.com/showinfo-26-57393-0.html代碼出錯(cuò)了，IDE竟然不報(bào)錯(cuò)？太詭異了....
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： Spring國(guó)際化的應(yīng)用及原理詳解
下一篇： Elasticsearch 8.X 小技巧：使用存儲(chǔ)腳本優(yōu)化數(shù)據(jù)索引與轉(zhuǎn)換過(guò)程
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)