Java精選面試題（微信小程序）：5000+道面試題和選擇題，真實面經(jīng)，簡歷模版，包含Java基礎、并發(fā)、JVM、線程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架構設計、大廠真題等，在線隨時刷題！

看到這樣的代碼，內(nèi)心五味雜陳

那天下午，看到了令我終生難忘的代碼，那一刻破防了......

本文記錄那些年的 Java 代碼軼事

ヾ(?ω?`) 故事還得從半年前數(shù)據(jù)隔離的那個事情說起......

歷史背景

數(shù)據(jù)隔離

預發(fā)，灰度，線上環(huán)境共用一個數(shù)據(jù)庫。每一張表有一個 env 字段，環(huán)境不同值不同。特別說明：env 字段即環(huán)境字段。如下圖所示：

隔離之前

?插曲：一開始只有 1 個核心表有 env 字段，其他表均無該字段；有一天預發(fā)環(huán)境的操作影響到客戶線上的數(shù)據(jù)。為了徹底隔離，剩余的二十幾個表均要添加上環(huán)境隔離字段。

「當時二十幾張表已經(jīng)大量生產(chǎn)數(shù)據(jù)，隔離需要做好兼容過渡，保障數(shù)據(jù)安全。」

隔離改造

其他表歷史數(shù)據(jù)很難做區(qū)分，于是新增加的字段 env 初始化 all ，表示預發(fā)線上都能訪問。以此達到歷史數(shù)據(jù)的兼容。

每一個環(huán)境都有一個自己獨立標志；從 application.properties 中讀該字段；最終到數(shù)據(jù)庫執(zhí)行的語句如下：

隔離方案

「最拉胯的做法：每一張表涉及到的 DO、Mapper、XML等挨個添加 env 字段。但我指定不能這么干！?。　?/p>

具體方案：自定義 mybatis 攔截器進行統(tǒng)一處理。通過這個方案可以解決以下幾個問題：

• 業(yè)務代碼不用修改，包括 DO、Mapper、XML等。只修改 mybatis 攔截的邏輯。

• 挨個添加補充字段，工程量很多，出錯概率極高

• 后續(xù)擴展容易

最終落地

在 mybatis 攔截器中， 通過改寫 SQL。新增時填充環(huán)境字段值，查詢時添加環(huán)境字段條件。真正實現(xiàn)改一處即可?？紤]歷史數(shù)據(jù)過渡，將 env = ${當前環(huán)境} 修改成 env in (${當前環(huán)境},'all')

具體實現(xiàn)邏輯如下圖所示：

1. 其中 env 字段是從 application.properties 配置獲取，全局唯一，只要環(huán)境不同，env 值不同

2. 借助 JSqlParser 開源工具，改寫 sql 語句，修改重新填充、查詢拼接條件即可。鏈接https://github.com/JSQLParser/JSqlParser

思路：自定義攔截器，填充環(huán)境參數(shù)，修改 sql 語句，下面是部分代碼示例：

@Intercepts(         {@Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class})} ) @Component public class EnvIsolationInterceptor implements Interceptor {     ......     @Override     publicObjectintercept(Invocation invocation) throwsThrowable {         ......         if (SqlCommandType.INSERT == sqlCommandType) {             try {                 // 重寫 sql 執(zhí)行語句，填充環(huán)境參數(shù)等                 insertMethodProcess(invocation, boundSql);             } catch (Exception exception) {                 log.error("parser insert sql exception, boundSql is:" + JSON.toJSONString(boundSql), exception);                 throwexception;             }         }         returninvocation.proceed();     } }

一氣呵成，完美上線。

發(fā)展演變

業(yè)務需求

「隨著業(yè)務發(fā)展，出現(xiàn)了以下需求：」

• 上下游合作，我們的 PRC 接口在匹配環(huán)境上與他們有差異，需要改造

• 有一些環(huán)境的數(shù)據(jù)相互相共享，比如預發(fā)和灰度等

• 開發(fā)人員的部分后面，希望在預發(fā)能糾正線上數(shù)據(jù)等

SELECT * FROM ${tableName} WHERE bizId = ${bizId} and env in (?,'all')

初步溝通

這個需求的落地交給了來了快兩年的小鮮肉。在開始做之前，他也問我該怎么做；我簡單說了一些想法，比如可以跳過環(huán)境字段檢查，不拼接條件；或者拼接所有條件，這樣都能查詢；亦或者看一下能不能注解來標志特定方法，你想一想如何實現(xiàn)......

(●ˇ?ˇ●)年紀大了需要給年輕人機會。

勤勞能干

小鮮肉，沒多久就實現(xiàn)了。不過有一天下午他遇到了麻煩。他填充的環(huán)境字段取出來為 null，看來很久沒找到原因，讓我?guī)退纯?。（不久前也還教過他 Arthas 如何使用呢，這種問題應該不在話下吧）

具體實現(xiàn)

大致邏輯：在需要跳過環(huán)境條件判斷的方法前后做硬編碼處理，同環(huán)切面邏輯， 一加一刪。填充顏色部分為小鮮肉的改造邏輯。

大概邏輯就是：將 env 字段填充所有環(huán)境。條件過濾的忽略的目的。

SELECT * FROM ${tableName} WHERE env in ('pre','gray','online','all') AND ${其他條件}

錯誤原因

經(jīng)過排查是因為 API 里面有多處對 threadLoal 進行處理的邏輯，方法之間存在調用。簡化舉例：A 和 B 方法都是獨立的方法， A 在調用 B 的過程，B 結束時把上下文環(huán)境字段刪除， A 在獲取時得到 null。具體如下：

五味雜陳

當我看到代碼的一瞬間，徹底破防了......

「queryProject 方法里面調用 findProjectWithOutEnv， 在兩個方法中，都有填充處理 env 的代碼?！?/p>

遍地開花

然而，這三行代碼，隨處可見，在業(yè)務代碼中遍地開花.......

// 1. 變量保存 oriFilterEnv String oriFilterEnv = UserHolder.getUser().getFilterEnv(); // 2. 設置值到應用上下文 UserHolder.getUser().setFilterEnv(globalConfigDTO.getAllEnv()); //....... 業(yè)務代碼 .... // 3. 結束復原 UserHolder.getUser().setFilterEnv(oriFilterEnv);

改了個遍，很勤勞......

靈魂開問

「難道真的就只能這么做嗎，當然還有......」

• 開閉原則符合了嗎

• 改漏了應該辦呢

• 其他人遇到跳過的檢查的場景也加這樣的代碼嗎

• 業(yè)務代碼和功能代碼分離了嗎

• 填充到應用上下文對象 user 合適嗎

「大量魔法值，單行字符超500，方法長度拖幾個屏幕也都睜一眼閉一只眼了，但整這一出，還是破防......」

內(nèi)心涌動，我覺得要重構一下。

重構一下

困難之處

「在 mybatis intercept 中不能直接精準地獲取到 service 層的接口調用。只能通過棧幀查詢到調用鏈?！?/p>

問題列表

• 盡量不要修改已有方法，保證不影響原有邏輯；

• 盡量不要在業(yè)務方法中修改功能代碼；關注點分離；

• 盡量最小改動，修改一處即可實現(xiàn)邏輯；

• 改造后復用能力，而不是依葫蘆畫瓢地添加這種代碼

實現(xiàn)分析

用獨立的 ThreadLocal，不與當前用戶信息上下文混合使用

注解+APO，通過注解參數(shù)解析，達到目標功能

對于方法之間的調用或者循環(huán)調用，要考慮優(yōu)化

「同一份代碼，在多個環(huán)境運行，不管如何，一定要考慮線上數(shù)據(jù)安全性。」

使用案例

改造后的使用案例如下，案例說明：「project 表在預發(fā)環(huán)境校驗跳過」 。

@SneakyThrows @GetMapping("/importSignedUserData") @InvokeChainSkipEnvRule(skipEnvList = {"pre"}, skipTableList = {"project"}) public void importSignedUserData(     ......     HttpServletRequest request,     HttpServletResponse response) {     ...... }

「在使用的調用入口處添加注解。」

具體實現(xiàn)

1. 方法上標記注解， 注解參數(shù)定義規(guī)則

2. 切面讀取方法上面的注解規(guī)則，并傳遞到應用上下文

3. 攔截器從應用上下文讀取規(guī)則進行規(guī)則判斷

注解代碼

@Target({ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) public @interface InvokeChainSkipEnvRule {     /**      * 是否跳過環(huán)境。默認 true，不推薦設置 false      *      * @return      */     booleanisKip() defaulttrue;     /**      * 賦值則判斷規(guī)則，否則不判斷      *      * @return      */     String[]skipEnvList() default {};     /**      * 賦值則判斷規(guī)則，否則不判斷      *      * @return      */     String[]skipTableList() default {}; }

不足之處

1. 整個鏈路上的這個表操作都會跳過，顆粒度還是比較粗

2. 注解只能在入口處使用，公共方法調用盡量避免

那還要不要完善一下，還有什么沒有考慮到的點呢？拿起手機看到快12點的那一刻，我還是選擇先回家了......

總結思考

隔離總結

這是一個很好參考案例：在應用中既做了數(shù)據(jù)隔離，也做了數(shù)據(jù)共享。通過自定義攔截器做數(shù)據(jù)隔離，通過自定注解切面實現(xiàn)數(shù)據(jù)共享。

編碼總結

「同樣的代碼寫兩次就應該考慮重構了」

• 盡量修改一個地方，不要寫這種邊邊角角的代碼

• 善用自定義注解，解決這種通用邏輯

• 可以妥協(xié)，但是要有底線

場景總結

「簡單梳理，自定義注解 + AOP 的場景」

自定義注解很靈活，應用場景廣泛，可以多多挖掘。

反思總結

• 如果一開始就做好技術方案或者直接使用不同的數(shù)據(jù)庫

• 是否可以拒絕那個所謂的需求

• 先有設計再有編碼，別瞎搞

最后感想

在這個只講業(yè)務結果，不講技術氛圍的環(huán)境里，突然有一些傷感；身體已經(jīng)開始吃不消了，好像也過了那個對技術較真死摳的年紀；突然一想，這么做的意義又有多大呢?

來源：https://juejin.cn/post/7294844864020430902

公眾號“Java精選”所發(fā)表內(nèi)容注明來源的，版權歸原出處所有（無法查證版權的或者未注明出處的均來自網(wǎng)絡，系轉載，轉載的目的在于傳遞更多信息，版權屬于原作者。如有侵權，請聯(lián)系，筆者會第一時間刪除處理！

最近有很多人問，有沒有讀者交流群！加入方式很簡單，公眾號Java精選，回復“加群”，即可入群！

文章有幫助的話，點在看，轉發(fā)吧！