基本概念
Prompts提示詞
?提示詞的是引導AI模型輸出的輸入,提示詞的正確性直接影響模型輸出的。
Message消息
Message 接口封裝了 Prompt 文本內容、一組元數據屬性以及稱為 MessageType 的分類。Spring AI消息API:

其中最重要的就是角色:
System Role:?系統角色
User Role:? 用戶角色
Assistant Role:?輔助角色
Tool/Function Role:工具/函數角色:工具/函數角色專注于在響應工具調用助手消息時返回額外信息。
PromptTemplate提示詞模板
?Spring AI 中用于提示模板的關鍵組件是 PromptTemplate 類,該類旨在簡化結構化提示的創建,然后將其發送到 AI 模型進行處理。
eg:
PromptTemplate promptTemplate =?new?PromptTemplate("Tell me a {adjective} joke about {topic}");Prompt prompt = promptTemplate.create(Map.of("adjective", adjective,?"topic", topic));return?chatModel.call(prompt).getResult();
創建有效的提示
未定義角色的測試

定義模型角色
@Configuration
public?class?CustomAIConfig?{@Beanpublic?ChatClient?chatClient(ChatClient.Builder builder)?{return?builder.defaultSystem("你是資深的Java架構師,你精通Java開發,Spring全家桶"?+"你的名字JavaBoy。你需要專業的回答用戶提出的java方面的問題!").build();}
}

具體問題:

提示詞模板
?推薦一個比較常用的提示詞模板
角色+任務+輸出:
系統角色:?AI是一個資深Java架構師,精通Java技術.
用戶角色:我是一名剛入門Java的開發工程師.任務或者請求:加鎖和加事務的先后順序和不同順序可能會產生的影響。
輸出:?輸出一個實際開發加鎖和加事務的例子說明影響
?加鎖與事務的基本概念 1.?鎖(Lock): 用于控制對共享資源的并發訪問 2.?事務(Transaction): 保證一組操作要么全部成功,要么全部失敗 ## 順序影響分析
情況1:先加鎖后加事務
// 偽代碼示例?
lock.lock();?
// 先獲取鎖?
try?{?@Transactional?
// 后開啟事務?
public?void?method()?{?
// 業務邏輯 } }?
finally?{
lock.unlock();?
}
問題: - 鎖的范圍大于事務范圍 - 事務提交前鎖可能已經釋放,導致其他線程看到中間狀態 - 可能導致死鎖,因為事務持有鎖的時間過長
情況2:先加事務后加鎖
// 偽代碼示例?
@Transactional?
// 先開啟事務?
public?void?method()?{?
lock.lock();?
// 后獲取鎖 try {?
// 業務邏輯?
}?finally?{
lock.unlock();?
}?
}
優點: - 鎖的范圍在事務范圍內 - 事務提交前鎖不會釋放,保證一致性 - 更符合ACID原則 ## 實際開發示例 假設我們有一個銀行轉賬場景:
@Service?
publicclass?BankService?{
privatefinal?Map accounts =?new?ConcurrentHashMap<>();?
privatefinal?ReentrantLock transferLock =?new?ReentrantLock();
// 正確的做法:事務內加鎖?
@Transactional
public?void?transferMoney(String fromId, String toId, BigDecimal amount)?{?
transferLock.lock();?
try?{?Account fromAccount = accounts.get(fromId);?Account toAccount = accounts.get(toId);if?(fromAccount.getBalance().compareTo(amount) <?0) {?thrownew?InsufficientFundsException(); } fromAccount.setBalance(fromAccount.getBalance().subtract(amount));toAccount.setBalance(toAccount.getBalance().add(amount));?}?finally?{?transferLock.unlock();?}?}?// 錯誤的做法:鎖內加事務?public?void?transferMoneyWrong(String fromId, String toId, BigDecimal amount)?{ transferLock.lock();?try?{?// 事務范圍在鎖內?doTransfer(fromId, toId, amount); ? ? }finally?{?transferLock.unlock();?}?}?@Transactionalprivate?void?doTransfer(String fromId, String toId, BigDecimal amount)?{?// 轉賬邏輯?}?}
最佳實踐建議 1.?推薦順序: 先開啟事務,再獲取鎖 2.?鎖的范圍: 盡量縮小鎖的范圍,只鎖必要的代碼塊 3.?鎖的類型選擇: - 讀多寫少: 考慮讀寫鎖(ReentrantReadWriteLock) - 高競爭: 考慮樂觀鎖(版本號機制) 4.?事務隔離級別: 根據業務需求選擇合適的隔離級別 記住,鎖和事務的正確使用對系統性能和一致性至關重要。在復雜場景下,可能需要結合分布式鎖和分布式事務來處理跨服務的問題。