結合實戰和源碼來聊聊Java中的SPI機制？
寫在前面
SPI機制可以很是方便的爲某個接口動態指定其實現類，在某種程度上，這也是某些框架具備高度可擴展性的基礎。今天，咱們就從源碼級別深刻探討下Java中的SPI機制。注：文章已收錄到：https://github.com/sunshinelyz/technology-binghejava
SPI的概念
SPI在Java中的全稱爲Service Provider Interface，是JDK內置的一種服務提供發現機制，是Java提供的一套用來被第三方實現或者擴展的API，它能夠用來啓用框架擴展和替換組件。git
JAVA SPI = 基於接口的編程＋策略模式＋配置文件的動態加載機制
SPI的使用場景
Java是一種面嚮對象語言，雖然Java8開始支持函數式編程和Stream，可是整體來講，仍是面向對象的語言。在使用Java進行面向對象開發時，通常會推薦使用基於接口的編程，程序的模塊與模塊以前不會直接進行實現類的硬編碼。而在實際的開發過程當中，每每一個接口會有多個實現類，各實現類要麼實現的邏輯不一樣，要麼使用的方式不一樣，還有的就是實現的技術不一樣。爲了使調用方在調用接口的時候，明確的知道本身調用的是接口的哪一個實現類，或者說爲了實如今模塊裝配的時候不用在程序裏動態指明，這就須要一種服務發現機制。Java中的SPI加載機制可以知足這樣的需求，它可以自動尋找某個接口的實現類。程序員
大量的框架使用了Java的SPI技術，以下：github
（1）JDBC加載不一樣類型的數據庫驅動
（2）日誌門面接口實現類加載，SLF4J加載不一樣提供商的日誌實現類
（3）Spring中大量使用了SPI面試
- 對servlet3.0規範
- 對ServletContainerInitializer的實現
- 自動類型轉換Type Conversion SPI(Converter SPI、Formatter SPI)等
（4）Dubbo裏面有不少個組件，每一個組件在框架中都是以接口的造成抽象出來！具體的實現又分不少種，在程序執行時根據用戶的配置來按需取接口的實現spring
SPI的使用
當服務的提供者，提供了接口的一種實現後，須要在Jar包的META-INF/services/目錄下，建立一個以接口的名稱（包名.接口名的形式）命名的文件，在文件中配置接口的實現類（完整的包名+類名）。數據庫
當外部程序經過java.util.ServiceLoader類裝載這個接口時，就可以經過該Jar包的META/Services/目錄裏的配置文件找到具體的實現類名，裝載實例化，完成注入。同時，SPI的規範規定了接口的實現類必須有一個無參構造方法。apache
SPI中查找接口的實現類是經過java.util.ServiceLoader，而在java.util.ServiceLoader類中有一行代碼以下：編程
// 加載具體實現類信息的前綴，也就是以接口命名的文件須要放到Jar包中的META-INF/services/目錄下 private static final String PREFIX = "META-INF/services/";
這也就是說，咱們必須將接口的配置文件寫到Jar包的META/Services/目錄下。緩存
SPI實例
這裏，給出一個簡單的SPI使用實例，演示在Java程序中如何使用SPI動態加載接口的實現類。
注意：實例是基於Java8進行開發的。
1.建立Maven項目
在IDEA中建立Maven項目spi-demo，以下：
2.編輯pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<artifactId>spi-demo</artifactId>
<groupId>io.binghe.spi</groupId>
<packaging>jar</packaging>
<version>1.0.0-SNAPSHOT</version>
<modelVersion>4.0.0</modelVersion>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.0</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
3.建立類加載工具類
在io.binghe.spi.loader包下建立MyServiceLoader，MyServiceLoader類中直接調用JDK的ServiceLoader類加載Class。代碼以下所示。
package io.binghe.spi.loader;
import java.util.ServiceLoader;
/**
* @author binghe
* @version 1.0.0
* @description 類加載工具
*/
public class MyServiceLoader {
/**
* 使用SPI機制加載全部的Class
*/
public static <S> ServiceLoader<S> loadAll(final Class<S> clazz) {
return ServiceLoader.load(clazz);
}
}
4.建立接口
在io.binghe.spi.service包下建立接口MyService，做爲測試接口，接口中只有一個方法，打印傳入的字符串信息。代碼以下所示：
package io.binghe.spi.service;
/**
* @author binghe
* @version 1.0.0
* @description 定義接口
*/
public interface MyService {
/**
* 打印信息
*/
void print(String info);
}
5.建立接口的實現類
（1）建立第一個實現類MyServiceA
在io.binghe.spi.service.impl包下建立MyServiceA類，實現MyService接口。代碼以下所示：
package io.binghe.spi.service.impl;
import io.binghe.spi.service.MyService;
/**
* @author binghe
* @version 1.0.0
* @description 接口的第一個實現
*/
public class MyServiceA implements MyService {
@Override
public void print(String info) {
System.out.println(MyServiceA.class.getName() + " print " + info);
}
}
（2）建立第二個實現類MyServiceB
在io.binghe.spi.service.impl包下建立MyServiceB類，實現MyService接口。代碼以下所示：
package io.binghe.spi.service.impl;
import io.binghe.spi.service.MyService;
/**
* @author binghe
* @version 1.0.0
* @description 接口第二個實現
*/
public class MyServiceB implements MyService {
@Override
public void print(String info) {
System.out.println(MyServiceB.class.getName() + " print " + info);
}
}
6.建立接口文件
在項目的src/main/resources目錄下建立META/Services/目錄，在目錄中建立io.binghe.spi.service.MyService文件，注意：文件必須是接口MyService的全名，以後將實現MyService接口的類配置到文件中，以下所示：
io.binghe.spi.service.impl.MyServiceA io.binghe.spi.service.impl.MyServiceB
7.建立測試類
在項目的io.binghe.spi.main包下建立Main類，該類爲測試程序的入口類，提供一個main()方法，在main()方法中調用ServiceLoader類加載MyService接口的實現類。並經過Java8的Stream將結果打印出來，以下所示：
package io.binghe.spi.main;
import io.binghe.spi.loader.MyServiceLoader;
import io.binghe.spi.service.MyService;
import java.util.ServiceLoader;
import java.util.stream.StreamSupport;
/**
* @author binghe
* @version 1.0.0
* @description 測試的main方法
*/
public class Main {
public static void main(String[] args){
ServiceLoader<MyService> loader = MyServiceLoader.loadAll(MyService.class);
StreamSupport.stream(loader.spliterator(), false).forEach(s -> s.print("Hello World"));
}
}
8.測試實例
運行Main類中的main()方法，打印出的信息以下所示：
io.binghe.spi.service.impl.MyServiceA print Hello World io.binghe.spi.service.impl.MyServiceB print Hello World Process finished with exit code 0
經過打印信息能夠看出，經過Java SPI機制正確加載出接口的實現類，並調用接口的實現方法。
源碼解析
這裏，主要是對SPI的加載流程涉及到的java.util.ServiceLoader的源碼的解析。
進入java.util.ServiceLoader的源碼，能夠看到ServiceLoader類實現了java.lang.Iterable接口，以下所示。
public final class ServiceLoader<S> implements Iterable<S>
說明ServiceLoader類是能夠遍歷迭代的。
java.util.ServiceLoader類中定義了以下的成員變量：
// 加載具體實現類信息的前綴，也就是以接口命名的文件須要放到Jar包中的META-INF/services/目錄下 private static final String PREFIX = "META-INF/services/"; // 須要加載的接口 private final Class<S> service; // 類加載器，用於加載以接口命名的文件中配置的接口的實現類 private final ClassLoader loader; // 建立ServiceLoader時採用的訪問控制上下文環境 private final AccessControlContext acc; // 用來緩存已經加載的接口實現類，其中，Key是接口實現類的完整類名，Value爲實現類對象 private LinkedHashMap<String,S> providers = new LinkedHashMap<>(); // 用於延遲加載實現類的迭代器 private LazyIterator lookupIterator;
能夠看到ServiceLoader類中定義了加載前綴爲「META-INF/services/」，因此，接口文件必需要在項目的src/main/resources目錄下的META-INF/services/目錄下建立。
從MyServiceLoader類調用ServiceLoader.load(clazz)方法進入源碼，以下所示：
//根據類的Class對象加載指定的類，返回ServiceLoader對象
public static <S> ServiceLoader<S> load(Class<S> service) {
//獲取當前線程的類加載器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
//動態加載指定的類，將類加載到ServiceLoader中
return ServiceLoader.load(service, cl);
}
方法中調用了ServiceLoader.load(service, cl)方法，繼續跟蹤代碼，以下所示：
//經過ClassLoader加載指定類的Class，並將返回結果封裝到ServiceLoader對象中
public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader){
return new ServiceLoader<>(service, loader);
}
能夠看到ServiceLoader.load(service, cl)方法中，調用了ServiceLoader類的構造方法，繼續跟進代碼，以下所示：
//構造ServiceLoader對象
private ServiceLoader(Class<S> svc, ClassLoader cl) {
//若是傳入的Class對象爲空，則判處空指針異常
service = Objects.requireNonNull(svc, "Service interface cannot be null");
//若是傳入的ClassLoader爲空，則經過ClassLoader.getSystemClassLoader()獲取，不然直接使用傳入的ClassLoader
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
繼續跟reload()方法，以下所示。
//從新加載
public void reload() {
//清空保存加載的實現類的LinkedHashMap
providers.clear();
//構造延遲加載的迭代器
lookupIterator = new LazyIterator(service, loader);
}
繼續跟進懶加載迭代器的構造函數，以下所示。
private LazyIterator(Class<S> service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
能夠看到，會將須要加載的接口的Class對象和類加載器賦值給LazyIterator的成員變量。
當咱們在程序中迭代獲取對象實例時，首先在成員變量providers中查找是否有緩存的實例對象。若是存在則直接返回，不然調用lookupIterator延遲加載迭代器進行加載。
迭代器進行邏輯判斷的代碼以下所示：
//迭代ServiceLoader的方法
public Iterator<S> iterator() {
return new Iterator<S>() {
//獲取保存實現類的LinkedHashMap<String,S>的迭代器
Iterator<Map.Entry<String,S>> knownProviders = providers.entrySet().iterator();
//判斷是否有下一個元素
public boolean hasNext() {
//若是knownProviders存在元素，則直接返回true
if (knownProviders.hasNext())
return true;
//返回延遲加載器是否存在元素
return lookupIterator.hasNext();
}
//獲取下一個元素
public S next() {
//若是knownProviders存在元素，則直接獲取
if (knownProviders.hasNext())
return knownProviders.next().getValue();
//獲取延遲迭代器lookupIterator中的元素
return lookupIterator.next();
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
LazyIterator加載類的流程以下代碼所示
//判斷是否擁有下一個實例
private boolean hasNextService() {
//若是擁有下一個實例，直接返回true
if (nextName != null) {
return true;
}
//若是實現類的全名爲null
if (configs == null) {
try {
//獲取全文件名，文件相對路徑+文件名稱（包名+接口名）
String fullName = PREFIX + service.getName();
//類加載器爲空，則經過ClassLoader.getSystemResources()方法獲取
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
//類加載器不爲空，則直接經過類加載器獲取
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}
}
while ((pending == null) || !pending.hasNext()) {
//若是configs中沒有更過的元素，則直接返回false
if (!configs.hasMoreElements()) {
return false;
}
//解析包結構
pending = parse(service, configs.nextElement());
}
nextName = pending.next();
return true;
}
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
//加載類對象
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
fail(service,
"Provider " + cn + " not found");
}
if (!service.isAssignableFrom(c)) {
fail(service,
"Provider " + cn + " not a subtype");
}
try {
//經過c.newInstance()生成對象實例
S p = service.cast(c.newInstance());
//將生成的對象實例保存到緩存中（LinkedHashMap<String,S>）
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
throw new Error(); // This cannot happen
}
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public S next() {
if (acc == null) {
return nextService();
} else {
PrivilegedAction<S> action = new PrivilegedAction<S>() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
最後，給出整個java.util.ServiceLoader的類，以下所示：
package java.util;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;
import java.security.AccessControlContext;
import java.security.AccessController;
import java.security.PrivilegedAction;
public final class ServiceLoader<S> implements Iterable<S> {
// 加載具體實現類信息的前綴，也就是以接口命名的文件須要放到Jar包中的META-INF/services/目錄下
private static final String PREFIX = "META-INF/services/";
// 須要加載的接口
private final Class<S> service;
// 類加載器，用於加載以接口命名的文件中配置的接口的實現類
private final ClassLoader loader;
// 建立ServiceLoader時採用的訪問控制上下文環境
private final AccessControlContext acc;
// 用來緩存已經加載的接口實現類，其中，Key是接口實現類的完整類名，Value爲實現類對象
private LinkedHashMap<String,S> providers = new LinkedHashMap<>();
// 用於延遲加載實現類的迭代器
private LazyIterator lookupIterator;
//從新加載
public void reload() {
//清空保存加載的實現類的LinkedHashMap
providers.clear();
//構造延遲加載的迭代器
lookupIterator = new LazyIterator(service, loader);
}
//構造ServiceLoader對象
private ServiceLoader(Class<S> svc, ClassLoader cl) {
//若是傳入的Class對象爲空，則判處空指針異常
service = Objects.requireNonNull(svc, "Service interface cannot be null");
//若是傳入的ClassLoader爲空，則經過ClassLoader.getSystemClassLoader()獲取，不然直接使用傳入的ClassLoader
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
private static void fail(Class<?> service, String msg, Throwable cause)
throws ServiceConfigurationError
{
throw new ServiceConfigurationError(service.getName() + ": " + msg,
cause);
}
private static void fail(Class<?> service, String msg)
throws ServiceConfigurationError
{
throw new ServiceConfigurationError(service.getName() + ": " + msg);
}
private static void fail(Class<?> service, URL u, int line, String msg)
throws ServiceConfigurationError
{
fail(service, u + ":" + line + ": " + msg);
}
// Parse a single line from the given configuration file, adding the name
// on the line to the names list.
//
private int parseLine(Class<?> service, URL u, BufferedReader r, int lc,
List<String> names)
throws IOException, ServiceConfigurationError
{
String ln = r.readLine();
if (ln == null) {
return -1;
}
int ci = ln.indexOf('#');
if (ci >= 0) ln = ln.substring(0, ci);
ln = ln.trim();
int n = ln.length();
if (n != 0) {
if ((ln.indexOf(' ') >= 0) || (ln.indexOf('\t') >= 0))
fail(service, u, lc, "Illegal configuration-file syntax");
int cp = ln.codePointAt(0);
if (!Character.isJavaIdentifierStart(cp))
fail(service, u, lc, "Illegal provider-class name: " + ln);
for (int i = Character.charCount(cp); i < n; i += Character.charCount(cp)) {
cp = ln.codePointAt(i);
if (!Character.isJavaIdentifierPart(cp) && (cp != '.'))
fail(service, u, lc, "Illegal provider-class name: " + ln);
}
if (!providers.containsKey(ln) && !names.contains(ln))
names.add(ln);
}
return lc + 1;
}
private Iterator<String> parse(Class<?> service, URL u)
throws ServiceConfigurationError
{
InputStream in = null;
BufferedReader r = null;
ArrayList<String> names = new ArrayList<>();
try {
in = u.openStream();
r = new BufferedReader(new InputStreamReader(in, "utf-8"));
int lc = 1;
while ((lc = parseLine(service, u, r, lc, names)) >= 0);
} catch (IOException x) {
fail(service, "Error reading configuration file", x);
} finally {
try {
if (r != null) r.close();
if (in != null) in.close();
} catch (IOException y) {
fail(service, "Error closing configuration file", y);
}
}
return names.iterator();
}
// Private inner class implementing fully-lazy provider lookupload
private class LazyIterator
implements Iterator<S>
{
Class<S> service;
ClassLoader loader;
Enumeration<URL> configs = null;
Iterator<String> pending = null;
String nextName = null;
private LazyIterator(Class<S> service, ClassLoader loader) {
this.service = service;
this.loader = loader;
}
//判斷是否擁有下一個實例
private boolean hasNextService() {
//若是擁有下一個實例，直接返回true
if (nextName != null) {
return true;
}
//若是實現類的全名爲null
if (configs == null) {
try {
//獲取全文件名，文件相對路徑+文件名稱（包名+接口名）
String fullName = PREFIX + service.getName();
//類加載器爲空，則經過ClassLoader.getSystemResources()方法獲取
if (loader == null)
configs = ClassLoader.getSystemResources(fullName);
else
//類加載器不爲空，則直接經過類加載器獲取
configs = loader.getResources(fullName);
} catch (IOException x) {
fail(service, "Error locating configuration files", x);
}
}
while ((pending == null) || !pending.hasNext()) {
//若是configs中沒有更過的元素，則直接返回false
if (!configs.hasMoreElements()) {
return false;
}
//解析包結構
pending = parse(service, configs.nextElement());
}
nextName = pending.next();
return true;
}
private S nextService() {
if (!hasNextService())
throw new NoSuchElementException();
String cn = nextName;
nextName = null;
Class<?> c = null;
try {
//加載類對象
c = Class.forName(cn, false, loader);
} catch (ClassNotFoundException x) {
fail(service,
"Provider " + cn + " not found");
}
if (!service.isAssignableFrom(c)) {
fail(service,
"Provider " + cn + " not a subtype");
}
try {
//經過c.newInstance()生成對象實例
S p = service.cast(c.newInstance());
//將生成的對象實例保存到緩存中（LinkedHashMap<String,S>）
providers.put(cn, p);
return p;
} catch (Throwable x) {
fail(service,
"Provider " + cn + " could not be instantiated",
x);
}
throw new Error(); // This cannot happen
}
public boolean hasNext() {
if (acc == null) {
return hasNextService();
} else {
PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() {
public Boolean run() { return hasNextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public S next() {
if (acc == null) {
return nextService();
} else {
PrivilegedAction<S> action = new PrivilegedAction<S>() {
public S run() { return nextService(); }
};
return AccessController.doPrivileged(action, acc);
}
}
public void remove() {
throw new UnsupportedOperationException();
}
}
//迭代ServiceLoader的方法
public Iterator<S> iterator() {
return new Iterator<S>() {
//獲取保存實現類的LinkedHashMap<String,S>的迭代器
Iterator<Map.Entry<String,S>> knownProviders = providers.entrySet().iterator();
//判斷是否有下一個元素
public boolean hasNext() {
//若是knownProviders存在元素，則直接返回true
if (knownProviders.hasNext())
return true;
//返回延遲加載器是否存在元素
return lookupIterator.hasNext();
}
//獲取下一個元素
public S next() {
//若是knownProviders存在元素，則直接獲取
if (knownProviders.hasNext())
return knownProviders.next().getValue();
//獲取延遲迭代器lookupIterator中的元素
return lookupIterator.next();
}
public void remove() {
throw new UnsupportedOperationException();
}
};
}
//經過ClassLoader加載指定類的Class，並將返回結果封裝到ServiceLoader對象中
public static <S> ServiceLoader<S> load(Class<S> service,
ClassLoader loader)
{
return new ServiceLoader<>(service, loader);
}
//根據類的Class對象加載指定的類，返回ServiceLoader對象
public static <S> ServiceLoader<S> load(Class<S> service) {
//獲取當前線程的類加載器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
//動態加載指定的類，將類加載到ServiceLoader中
return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> loadInstalled(Class<S> service) {
ClassLoader cl = ClassLoader.getSystemClassLoader();
ClassLoader prev = null;
while (cl != null) {
prev = cl;
cl = cl.getParent();
}
return ServiceLoader.load(service, prev);
}
/**
* Returns a string describing this service.
*
* @return A descriptive string
*/
public String toString() {
return "java.util.ServiceLoader[" + service.getName() + "]";
}
}
SPI總結
最後，對Java提供的SPI機制進行簡單的總結。
優勢：
可以實現項目解耦，使得第三方服務模塊的裝配控制的邏輯與調用者的業務代碼分離，而不是耦合在一塊兒。應用程序能夠根據實際業務狀況啓用框架擴展或替換框架組件。
缺點：
- 多個併發多線程使用ServiceLoader類的實例是不安全的
- 雖然ServiceLoader也算是使用的延遲加載，可是基本只能經過遍歷所有獲取，也就是接口的實現類所有加載並實例化一遍。
重磅福利
微信搜一搜【冰河技術】微信公衆號，關注這個有深度的程序員，天天閱讀超硬核技術乾貨，公衆號內回覆【PDF】有我準備的一線大廠面試資料和我原創的超硬核PDF技術文檔，以及我爲你們精心準備的多套簡歷模板（不斷更新中），但願你們都能找到心儀的工做，學習是一條時而鬱鬱寡歡，時而開懷大笑的路，加油。若是你經過努力成功進入到了心儀的公司，必定不要懈怠放鬆，職場成長和新技術學習同樣，不進則退。若是有幸咱們江湖再見！
另外，我開源的各個PDF，後續我都會持續更新和維護，感謝你們長期以來對冰河的支持！！
相關文章
- 1. 結合實戰和源碼來聊聊Java中的SPI機制？
- 2. dubbo源碼解析-從spi聊聊雙親委派機制
- 3. 聊聊Java的GC機制
- 4. 來聊聊源碼學習
- 5. 突破Java面試(36)-聊聊Dubbo的SPI機制
- 6. 由淺入深的來聊聊Golang中select的實現機制
- 7. 聊聊java反射機制
- 8. 聊聊Java的異常機制問題
- 9. 從源碼來聊一聊hashmap
- 10. 【java】從java SPI機制到dubbo SPI機制(源碼淺析)
- 更多相關文章...
- • Redis和數據庫的結合 - Redis教程
- • 現實生活中的 XML - XML 教程
- • 漫談MySQL的鎖機制
- • Java Agent入門實戰（二）-Instrumentation源碼概述
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. 融合阿里雲，牛客助您找到心儀好工作
- 2. 解決jdbc(jdbctemplate)在測試類時不報錯在TomCatb部署後報錯
- 3. 解決PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE無法輸入中文
- 4. vue+ant design中關於圖片請求不顯示的問題。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解決IDEA用Maven創建的Web工程不能創建Java Class文件的問題
- 7. [已解決] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea讓java文件夾正常使用
- 9. Eclipse啓動提示「subversive connector discovery」
- 10. 帥某-技巧-快速轉帖博主文章（article_content）
歡迎關注本站公眾號,獲取更多信息
