Apache Dubbo的SPI機制是如何實現(xiàn)的
一、SPI
1.1 JDK自帶SPI實現(xiàn)
從JDK1.6開始引入SPI機制后，可以看到很多使用SPI的案例，比如最常見的數(shù)據(jù)庫驅(qū)動實現(xiàn)，在JDK中只定義了java.sql.Driver的接口，具體實現(xiàn)由各數(shù)據(jù)庫廠商來提供。下面一個簡單的例子來快速了解下Java SPI的使用方式：
1）定義一個接口
package com.vivo.study
public interface Car {
void getPrice();
}
2）接口實現(xiàn)
package com.vivo.study.impl
/**
* 實現(xiàn)一
*
*/
public class AudiCar implements Car {
@Override
public void getPrice() {
System.out.println("Audi A6L's price is 500000 RMB.");
}
}
package com.vivo.study.impl
/**
* 實現(xiàn)二
*
*/
public class BydCar implements Car {
@Override
public void getPrice() {
System.out.println("BYD han's price is 220000 RMB.");
}
}
3）掛載擴展類信息
在META-INF/services目錄下以接口全名為文件名的文本文件，對應(yīng)此處即在META-INF/services目錄下創(chuàng)建一個文件名為com.vivo.study.Car的文件，文件內(nèi)容如下：
com.vivo.study.impl.AudiCar com.vivo.study.impl.BydCar
4）使用
public class SpiDemo {
public static void main(String[] args) {
ServiceLoader<Car> load = ServiceLoader.load(Car.class);
Iterator<Car> iterator = load.iterator();
while (iterator.hasNext()) {
Car car = iterator.next();
car.getPrice();
}
}
}
上面的例子簡單的介紹了JDK SPI機制的使用方式，其中最關(guān)鍵的類為ServiceLoader，通過ServiceLoader類來加載接口的實現(xiàn)類，ServiceLoader是Iterable接口的實現(xiàn)類，對于ServiceLoader加載的詳細過程此處不展開。
JDK對SPI的加載實現(xiàn)存在一個較為突出的小缺點，無法按需加載實現(xiàn)類，通過ServiceLoader.load加載時會將文件中的所有實現(xiàn)都進行實例化，如果想要獲取具體某個具體的實現(xiàn)類需要進行遍歷判斷。
1.2 Dubbo SPI
SPI擴展是Dubbo的最大的優(yōu)點之一，支持協(xié)議擴展、調(diào)用攔截擴展、引用監(jiān)聽擴展等等。在Dubbo中，根據(jù)不同的擴展定位，擴展文件分別被放置在META-INF/dubbo/internal/，META-INF/dubbo/，META-INF/services/這三個路徑下。
Dubbo中有直接使用JDK SPI實現(xiàn)的方式，比如org.apache.dubbo.common.extension.LoadingStrategy放在META-INF/services/路徑下，但大多情況下都是使用其自身對JDK SPI的實現(xiàn)的一種優(yōu)化方式，可稱為Dubbo SPI，也就是本文要講解的點。
相比于JDK的SPI的實現(xiàn)，Dubbo SPI具有以下特點：
配置形式更靈活：支持以key:value的形式在文件里配置類似name：xxx.xxx.xxx.xx，后續(xù)可以通過name來進行擴展類按需精準獲取。
緩存的使用：使用緩存提升性能，保證一個擴展實現(xiàn)類至多會加載一次。
對擴展類細分擴展：支持擴展點自動包裝(Wrapper)、擴展點自動裝配、擴展點自適應(yīng)（@Adaptive）、擴展點自動激活（@Activate）。
Dubbo對擴展點的加載主要由ExtensionLoader這個類展開。
二、加載-ExtensionLoader
ExtensionLoader在Dubbo里的角色類似ServiceLoader在JDK中的存在，用于加載擴展類。在Dubbo源碼里，隨處都可以見到ExtensionLoader的身影，比如在服務(wù)暴露里的關(guān)鍵類ServiceConfig中等，弄清楚ExtensionLoader的實現(xiàn)細節(jié)對閱讀Dubbo源碼有很大的幫助。
2.1 獲取ExtensionLoader的實例
ExtensionLoader沒有提供共有的構(gòu)造函數(shù)，
只能通過ExtensionLoader.getExtensionLoader(Class type)來獲取ExtensionLoader實例。
public
// ConcurrentHashMap緩存,key -> Class value -> ExtensionLoader實例
private static final ConcurrentMap<Class<?>, ExtensionLoader<?>> EXTENSION_LOADERS = new ConcurrentHashMap<>(64);
private ExtensionLoader(Class<?> type) {
this.type = type;
objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
}
public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type) {
if (type == null) {
throw new IllegalArgumentException("Extension type == null");
}
// 檢查是否是接口，如果不是則拋出異常
if (!type.isInterface()) {
throw new IllegalArgumentException("Extension type (" + type + ") is not an interface!");
}
// 檢查接口是否是被@SPI注解修飾，如果沒有則拋出異常
if (!withExtensionAnnotation(type)) {
throw new IllegalArgumentException("Extension type (" + type +
") is not an extension, because it is NOT annotated with @" + SPI.class.getSimpleName() + "!");
}
// 從緩存里取，沒有則初始化一個并放入緩存EXTENSION_LOADERS中
ExtensionLoader<T> loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
if (loader == null) {
EXTENSION_LOADERS.putIfAbsent(type, new ExtensionLoader<T>(type));
loader = (ExtensionLoader<T>) EXTENSION_LOADERS.get(type);
}
return loader;
}
}
上面的代碼展示了獲取ExtensionLoader實例的過程，可以看出，每一個被@SPI修飾的接口都會對應(yīng)同一個ExtensionLoader實例，且對應(yīng)ExtensionLoader只會被初始化一次，并緩存在ConcurresntHashMap中。
2.2 加載擴展類
加載擴展類入口，當(dāng)使用ExtensionLoader時，getExtensionName、getActivateExtension或是getDefaultExtension都要經(jīng)過getExtensionClasses方法來加載擴展類，如下圖；
getExtensionClasses方法調(diào)用的路徑如下圖，getExtensionClasses是加載擴展類的一個起點，會首先從緩存中獲取，如果緩存中沒有則通過loadExtensionClasses方法來加載擴展類，所以說實際上的加載邏輯入口在loadExtensionClasses。
getExtensionClasses
|->loadExtensionClasses
|->cacheDefaultExtensionName
|->loadDirectory
|->loadResource
|->loadClass
2.2.1 loadExtensionClasses加載擴展類
由于整個加載過程設(shè)計的源碼較多，因此用一個流程圖來進行描述，具體細節(jié)可以結(jié)合源碼進行查看。
loadExtensionClasses主要做了以下這幾件事：
默認擴展名：
抽取默認擴展實現(xiàn)名并緩存在ExtensionLoader里的cachedDefaultName，默認擴展名配置通過@SPI注解在接口上配置，如配置@SPI("defaultName")則默認擴展名為defaultName。
加載擴展類信息：
從META-INF/dubbo/internal/，META-INF/dubbo/,META-INF/services/這三個路徑下尋找以類的全路徑名命名的文件，并逐行讀取文件里的內(nèi)容。
加載class并緩存：
對擴展類分為自適應(yīng)擴展實現(xiàn)類(被@Adaptive修飾的實現(xiàn)類)、包裝類(擁有一個只有一個為這個接口類型的參數(shù)的構(gòu)造方法)、普通擴展類，其中普通擴展類中又包含自動激活擴展類（被@Activate修飾的類）和真普通的類，對自適應(yīng)擴展實現(xiàn)類、包裝類、自動激活擴展類這三種類型的類分別加載并分別緩存到cachedAdaptiveClass、cachedActivates、cachedWrapperClasses。
返回結(jié)果Map<String, Class<?>>：
結(jié)果返回Map，其中key對應(yīng)擴展文件里配置的name，value對應(yīng)擴展的類class，最后在getExtensionClasses方法里會將此結(jié)果放入緩存cachedClasses中。此結(jié)果Map中包含除了自適應(yīng)擴展實現(xiàn)類和包裝實現(xiàn)類的其他所用的擴展類名與對應(yīng)類的映射關(guān)系。
通過loadExtensionClasses方法把擴展類(Class對象)都加載到相應(yīng)的緩存中，是為了方便后面實例化擴展類對象，通過newInstance()等方法來實例化。
2.2.2擴展包裝類
什么是擴展包裝類？是不是類名結(jié)尾包含了Wrapper的類就是擴展包裝類？
在Dubbo SPI接口的實現(xiàn)擴展類中，如果此類包含一個此接口作為參數(shù)的構(gòu)造方法，則為擴展包裝類。擴展包裝類的作用是持有具體的擴展實現(xiàn)類，可以一層一層的被包裝，作用類似AOP。
包裝擴展類的作用是類似AOP，方便擴展增強。具體實現(xiàn)代碼如下：
從代碼中可以得出，可以通過boolean wrap選擇是否使用包裝類，默認情況下為true；如果有擴展包裝類，實際的實現(xiàn)類會被包裝類按一定的順序一層一層包起來。
如Protocol的實現(xiàn)類ProtocolFilterWrapper、ProtocolListenerWrapper都是擴展包裝類。
2.2.3自適應(yīng)擴展實現(xiàn)類
2.2.3.1 @Adaptive
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Adaptive {
String[] value() default {};
}
從源碼以及源碼注釋中可以得出以下幾點：
Adaptive是一個注解，可以修飾類（接口，枚舉）和方法。
此注解的作用是為ExtensionLoader注入擴展實例提供有用的信息。
從注釋中理解value的作用：
value可以決定選擇使用具體的擴展類。
通過value配置的值key，在修飾的方法的入?yún)rg.apache.dubbo.common.URL中通過key獲取到對應(yīng)的值value，根據(jù)value作為extensionName去決定使用對應(yīng)的擴展類。
如果通過2沒有找到對應(yīng)的擴展，會選擇默認的擴展類,通過@SPI配置默認擴展類。
2.2.3.2 @Adaptive簡單例子
由于@Adaptive修飾類時比較好理解，這里舉一個@Adaptive修飾方法的例子，使用@Adaptive修飾方法的這種情況在Dubbo也是隨處可見。
/**
* Dubbo SPI 接口
*/
@SPI("impl1")
public interface SimpleExt {
@Adaptive({"key1", "key2"})
String yell(URL url, String s);
}
如果調(diào)用
ExtensionLoader.getExtensionLoader(SimpleExt.class).getAdaptiveExtension().yell(url, s)方法，最終調(diào)用哪一個擴展類的實例去執(zhí)行yell方法的流程大致為：先獲取擴展類的名稱extName（對應(yīng)上面說的name:class中的name），然后通過extName來獲取對應(yīng)的類Class，再實例化進行調(diào)用。所以關(guān)鍵的步驟在怎么得到extName，上面的這個例子得到extName的流程為：
通過url.getParameters.get("key1")獲取，
沒有獲取到則用url.getParameters.get("key2"),如果還是沒有獲取到則使用impl1對應(yīng)的實現(xiàn)類，最后還是沒有獲取到則拋異常IllegalStateException。
可以看出，@Adaptive的好處就是可以通過方法入?yún)Q定具體調(diào)用哪一個實現(xiàn)類。下面會對@Adaptive的具體實現(xiàn)進行詳細分析。
2.2.3.3 @Adaptive加載流程
流程關(guān)鍵點說明：
1）黃色標記的，cachedAdaptiveClass是在ExtensionLoader#loadClass方法中加載Extension類時緩存的。
2）綠色標記的，如果Extension類中存在被@Adaptive修飾的類時會使用該類來初始化實例。
3）紅色標記的，如果Extension類中不存在被@Adaptive修飾的類時，則需要動態(tài)生成代碼，通過javassist（默認）來編譯生成Xxxx$Adaptive類來實例化。
4）實例化后通過injectExtension來將Adaptive實例的Extension注入（屬性注入）。
后續(xù)圍繞上述的關(guān)鍵點3詳細展開，關(guān)鍵點4此處不展開。
動態(tài)生成Xxx$Adaptive類：下面的代碼為動態(tài)生成Adaptive類的相關(guān)代碼，具體生成代碼的細節(jié)在AdaptiveClassCodeGenerator#generate中
public class ExtensionLoader<T> {
// ...
private Class<?> getAdaptiveExtensionClass() {
// 根據(jù)對應(yīng)的SPI文件加載擴展類并緩存，細節(jié)此處不展開
getExtensionClasses();
// 如果存在被@Adaptive修飾的類則直接返回此類
if (cachedAdaptiveClass != null) {
return cachedAdaptiveClass;
}
// 動態(tài)生成Xxxx$Adaptive類
return cachedAdaptiveClass = createAdaptiveExtensionClass();
}
private Class<?> createAdaptiveExtensionClass() {
// 生成Xxxx$Adaptive類代碼，可自行加日志或斷點查看生成的代碼
String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
ClassLoader classLoader = findClassLoader();
// 獲取動態(tài)編譯器，默認為javassist
org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
return compiler.compile(code, classLoader);
}
}
AdaptiveClassCodeGenerator#generate生成code的方式是通過字符串拼接，大量使用String.format,整個代碼過程比較繁瑣，可通過debug去了解細節(jié)。
最關(guān)鍵的的部分是生成被@Adaptive修飾的方法的內(nèi)容，也就是最終調(diào)用實例的@Adaptive方法時，可通過參數(shù)來動態(tài)選擇具體使用哪個擴展實例。下面對此部分進行分析：
public class AdaptiveClassCodeGenerator {
// ...
/**
* generate method content
*/
private String generateMethodContent(Method method) {
// 獲取方法上的@Adaptive注解
Adaptive adaptiveAnnotation = method.getAnnotation(Adaptive.class);
StringBuilder code = new StringBuilder(512);
if (adaptiveAnnotation == null) {
// 方法時沒有@Adaptive注解，生成不支持的代碼
return generateUnsupported(method);
} else {
// 方法參數(shù)里URL是第幾個參數(shù)，不存在則為-1
int urlTypeIndex = getUrlTypeIndex(method);
// found parameter in URL type
if (urlTypeIndex != -1) {
// Null Point check
code.append(generateUrlNullCheck(urlTypeIndex));
} else {
// did not find parameter in URL type
code.append(generateUrlAssignmentIndirectly(method));
}
// 獲取方法上@Adaptive配置的value
// 比如 @Adaptive({"key1","key2"}),則會返回String數(shù)組{"key1","key2"}
// 如果@Adaptive沒有配置value，則會根據(jù)簡寫接口名按駝峰用.分割，比如SimpleExt對應(yīng)simple.ext
String[] value = getMethodAdaptiveValue(adaptiveAnnotation);
// 參數(shù)里是否存在org.apache.dubbo.rpc.Invocation
boolean hasInvocation = hasInvocationArgument(method);
code.append(generateInvocationArgumentNullCheck(method));
// 生成String extName = xxx;的代碼 ，extName用于獲取具體的Extension實例
code.append(generateExtNameAssignment(value, hasInvocation));
// check extName == null?
code.append(generateExtNameNullCheck(value));
code.append(generateExtensionAssignment());
// return statement
code.append(generateReturnAndInvocation(method));
}
return code.toString();
}
}
上述生成Adaptive類的方法內(nèi)容中最關(guān)鍵的步驟在生成extName的部分，也就是generateExtNameAssignment(value,hasInvocation)，此方法if太多了（有點眼花繚亂）。
以下列舉幾個例子對此方法的實現(xiàn)流程進行簡單展示：假設(shè)方法中的參數(shù)不包含org.apache.dubbo.rpc.Invocation，包含org.apache.dubbo.rpc.Invocation的情況會更加復(fù)雜。
1）方法被@Adaptive修飾，沒有配置value，且在接口@SPI上配置了默認的實現(xiàn)
@SPI("impl1")
public interface SimpleExt {
@Adaptive
String echo(URL url, String s);
}
對應(yīng)生成extName的代碼為：
String extName = url.getParameter("simple.ext", "impl1")
2）方法被@Adaptive修飾，沒有配置value，且在接口@SPI上沒有配置默認的實現(xiàn)
@SPI("impl1")
public interface SimpleExt {
@Adaptive({"key1", "key2"})
String yell(URL url, String s);
}
對應(yīng)生成extName的代碼為：
String extName = url.getParameter( "simple.ext")
3）方法被@Adaptive修飾，配置了value（假設(shè)兩個，依次類推），且在接口@SPI上配置了默認的實現(xiàn)
@SPI
public interface SimpleExt {
@Adaptive({"key1", "key2"})
String yell(URL url, String s);
}
對應(yīng)生成extName的代碼為：
String extName = url.getParameter("key1", url.getParameter("key2", "impl1"));
4）方法被@Adaptive修飾，配置了value（假設(shè)兩個，依次類推），且在接口@SPI沒有配置默認的實現(xiàn)
@SPI
public interface SimpleExt {
@Adaptive({"key1", "key2"})
String yell(URL url, String s);
}
對應(yīng)生成extName的代碼為：
String extName = url.getParameter("key1", url.getParameter("key2"));
完整的生成類可參見附錄。
2.2.4自動激活擴展類
如果你有擴展實現(xiàn)過Dubbo的Filter，那么一定會對@Activate很熟悉。@Activate注解的作用是可以通過給定的條件來自動激活擴展實現(xiàn)類，通過ExtensionLoader#getActivateExtension(URL,String, String)方法可以找到指定條件下需要激活的擴展類列表。
下面以一個例子來對@Activate的作用進行說明，在Consumer調(diào)用Dubbo接口時，會經(jīng)過消費方的過濾器鏈以及提供方的過濾器鏈，在Provider暴露服務(wù)的過程中會拼接需要使用哪些Filter。
對應(yīng)源碼中的位置在ProtocolFilterWrapper#buildInvokerChain(invoker, key, group)方法中。
// export:key-> service.filter ; group-> provider
private static <T> Invoker<T> buildInvokerChain(final Invoker<T> invoker, String key, String group) {
// 在Provider暴露服務(wù)服務(wù)export時，會根據(jù)獲取Url中的service.filter對應(yīng)的值和group=provider來獲取激活對應(yīng)的Filter
List<Filter> filters = ExtensionLoader.getExtensionLoader(Filter.class).getActivateExtension(invoker.getUrl(), key, group);
}
ExtensionLoader#getActivateExtension(URL, String, String)是怎么根據(jù)條件來自動激活對應(yīng)的擴展類列表的可以自行查看該方法的代碼，此處不展開。
三、總結(jié)
本文主要對Dubbo SPI機制的擴展類加載過程通過ExtensionLoader類源碼來進行總結(jié)，可以概況為以下幾點：
1.Dubbo SPI結(jié)合了JDK SPI的實現(xiàn)，并在此基礎(chǔ)上進行優(yōu)化，如精準按需加載擴展類、緩存提升性能。
2.分析ExtensionLoader加載擴展類的過程，加載META-INF/dubbo/internal/，META-INF/dubbo/,META-INF/services/這三個路徑下的文件，并分類緩存在ExtensionLoader實例。
3.介紹擴展包裝類及其實現(xiàn)過程，擴展包裝類實現(xiàn)了類似AOP的功能。
4.自適應(yīng)擴展類，分析@Adptive修飾方法時動態(tài)生成Xxx$Adaptive類的過程，以及通過參數(shù)自適應(yīng)選擇擴展實現(xiàn)類完成方法調(diào)用的案例介紹。
簡單介紹自動激活擴展類及@Activate的作用。
四、附錄
4.1 Xxx$Adaptive完整案例
@SPI接口定義
@SPI("impl1")
public interface SimpleExt {
// @Adaptive example, do not specify a explicit key.
@Adaptive
String echo(URL url, String s);
@Adaptive({"key1", "key2"})
String yell(URL url, String s);
// no @Adaptive
String bang(URL url, int i);
}
生成的Adaptive類代碼
package org.apache.dubbo.common.extension.ext1;
import org.apache.dubbo.common.extension.ExtensionLoader;
public class SimpleExt$Adaptive implements org.apache.dubbo.common.extension.ext1.SimpleExt {
public java.lang.String yell(org.apache.dubbo.common.URL arg0, java.lang.String arg1) {
if (arg0 == null) throw new IllegalArgumentException("url == null");
org.apache.dubbo.common.URL url = arg0;
String extName = url.getParameter("key1", url.getParameter("key2", "impl1"));
if (extName == null)
throw new IllegalStateException("Failed to get extension (org.apache.dubbo.common.extension.ext1.SimpleExt) name from url (" + url.toString() + ") use keys([key1, key2])");
org.apache.dubbo.common.extension.ext1.SimpleExt extension = (org.apache.dubbo.common.extension.ext1.SimpleExt)ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.extension.ext1.SimpleExt.class).getExtension(extName);
return extension.yell(arg0, arg1);
}
public java.lang.String echo(org.apache.dubbo.common.URL arg0, java.lang.String arg1) {
if (arg0 == null) throw new IllegalArgumentException("url == null");
org.apache.dubbo.common.URL url = arg0;
String extName = url.getParameter("simple.ext", "impl1");
if (extName == null)
throw new IllegalStateException("Failed to get extension (org.apache.dubbo.common.extension.ext1.SimpleExt) name from url (" + url.toString() + ") use keys([simple.ext])");
org.apache.dubbo.common.extension.ext1.SimpleExt extension = (org.apache.dubbo.common.extension.ext1.SimpleExt) ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.extension.ext1.SimpleExt.class).getExtension(extName);
return extension.echo(arg0, arg1);
}
public java.lang.String bang(org.apache.dubbo.common.URL arg0, int arg1) {
throw new UnsupportedOperationException("The method public abstract java.lang.String org.apache.dubbo.common.extension.ext1.SimpleExt.bang(org.apache.dubbo.common.URL,int) of interface org.apache.dubbo.common.extension.ext1.SimpleExt is not adaptive method!");
}
}
以上就是Apache Dubbo的SPI機制是如何實現(xiàn)的的詳細內(nèi)容，更多關(guān)于Apache Dubbo的SPI機制的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
Lambda表達式類似匿名函數(shù)，簡單地說，它是沒有聲明的方法，也即沒有訪問修飾符、返回值聲明和方法名，這篇文章主要介紹了java8?中的lambda表達式簡介,需要的朋友可以參考下2022-06-06
這篇文章主要給大家介紹了關(guān)于Java文件、文件夾權(quán)限修改的兩種方法，文中通過示例代碼介紹的非常詳細，對大家學(xué)習(xí)或者使用Java具有一定的參考學(xué)習(xí)價值，需要的朋友們下面來一起學(xué)習(xí)學(xué)習(xí)吧2019-08-08
Java語言實現(xiàn)簡單FTP軟件 輔助功能模塊FTP站點管理實現(xiàn)(12)
這篇文章主要為大家詳細介紹了Java語言實現(xiàn)簡單FTP軟，輔助功能模塊FTP站點管理的實現(xiàn)方法，具有一定的參考價值，感興趣的小伙伴們可以參考一下2017-04-04
這篇文章主要為大家詳細介紹了java.mail實現(xiàn)發(fā)送郵件，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2020-02-02
使用HandlerMethodArgumentResolver用于統(tǒng)一獲取當(dāng)前登錄用戶
這篇文章主要介紹了使用HandlerMethodArgumentResolver用于統(tǒng)一獲取當(dāng)前登錄用戶實例，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2022-12-12
SpringCloud集成和使用OpenFeign的教程指南
在微服務(wù)架構(gòu)中,服務(wù)間的通信是至關(guān)重要的,SpringCloud作為一個功能強大的微服務(wù)框架,為我們提供了多種服務(wù)間通信的方式,其中,OpenFeign是一個聲明式的Web服務(wù)客戶端,它使得編寫Web服務(wù)客戶端變得更加簡單,本文將詳細介紹如何在SpringCloud項目中集成和使用OpenFeign2024-10-10
這篇文章主要介紹了java 使用過濾器實現(xiàn)登錄攔截處理方式，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-09-09
這篇文章主要介紹了JMagick實現(xiàn)基本圖像處理的類,實例分析了java圖像處理的相關(guān)技巧,需要的朋友可以參考下2015-06-06
本篇文章主要介紹了淺談Java中的高精度整數(shù)和高精度小數(shù)，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2017-08-08
Java中do-while循環(huán)的使用方法及注意事項詳解
這篇文章主要介紹了Java中do-while循環(huán)的使用方法及注意事項的相關(guān)資料,在Java編程中,do-while循環(huán)是一種基本的循環(huán)控制結(jié)構(gòu),它至少執(zhí)行一次循環(huán)體,然后根據(jù)條件判斷是否繼續(xù),文中將用法介紹的非常詳細,需要的朋友可以參考下2024-10-10