编写Java的坑有哪些

发布时间:2021-11-03 15:33:35 作者:iii
来源:亿速云 阅读:114

本篇内容主要讲解“编写Java的坑有哪些”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“编写Java的坑有哪些”吧!

1、对象比较方法

JDK 1.7 提供的 Objects.equals 方法,非常方便地实现了对象的比较,有效地避免了繁琐的空指针检查。

问题现象

在 JDK1.7 之前,在判断一个短整型、整型、长整型包装数据类型与常量是否相等时,我们一般这样写:

Short shortValue = (short)12345; System.out.println(shortValue == 12345); // true Integer intValue = 12345; System.out.println(intValue == 12345); // true Long longValue = 12345L; System.out.println(longValue == 12345); // true

从 JDK1.7 之后,提供了 Objects.equals 方法,并推荐使用函数式编程,更改代码如下:

Short shortValue = (short)12345; System.out.println(Objects.equals(shortValue, 12345)); // false Integer intValue = 12345; System.out.println(Objects.equals(intValue, 12345)); // true Long longValue = 12345L; System.out.println(Objects.equals(longValue, 12345)); // false

为什么直接把 == 替换为 Objects.equals 方法就会导致输出结果不一样?

问题分析

通过反编译第一段代码,我们得到语句 System.out.println(shortValue == 12345); 的字节码指令如下:

getstatic java.lang.System.out : java.io.PrintStream [22] aload_1 [shortValue] invokevirtual java.lang.Short.shortValue() : short [28] sipush 12345 if_icmpne 24 iconst_1 goto 25 iconst_0 invokevirtual java.io.PrintStream.println(boolean) : void [32]

原来,编译器会判断包装数据类型对应的基本数据类型,并采用这个基本数据类型的指令进行比较(比如上面字节码指令中的 sipush 和 if_icmpne  等),相当于编译器自动对常量进行了数据类型的强制转化。

为什么采用 Objects.equals 方法后,编译器不自动对常量进行数据类型的强制转化?通过反编译第二段代码,我们得到语句  System.out.println(Objects.equals(shortValue, 12345)); 的字节码指令如下:

getstatic java.lang.System.out : java.io.PrintStream [22] aload_1 [shortValue] sipush 12345 invokestatic java.lang.Integer.valueOf(int) : java.lang.Integer [28]   invokestatic java.util.Objects.equals(java.lang.Object, java.lang.Object) : boolean [33] invokevirtual java.io.PrintStream.println(boolean) : void [39]

原来,编译器根据字面意思,认为常量 12345 默认基本数据类型是 int,所以会自动转化为包装数据类型 Integer。

在 Java 语言中,整数的默认数据类型是 int,小数的默认数据类型是 double。

通过分析Objects.equals方法的源代码可知:语句System.out.println(Objects.equals(shortValue,  12345)),因为 Objects.equals 的两个参数对象类型不一致,一个是包装数据类型 Short,另一个是包装数据类型  Integer,所以最终的比较结果必然是false;而语句 System.out.println(Objects.equals(intValue,  12345)),因为Objects.equals 的两个参数对象类型一致,都是包装数据类型 Integer 且取值相同,所以最终的比较结果必然是  true。

避坑方法

1)保持良好的编码习惯,避免数据类型的自动转化

为了避免数据类型自动转化,更科学的写法是直接声明常量为对应的基本数据类型。

第一段代码可以这样写:

Short shortValue = (short)12345; System.out.println(shortValue == (short)12345); // true Integer intValue = 12345; System.out.println(intValue == 12345); // true Long longValue = 12345L; System.out.println(longValue == 12345L); // true

第二段代码可以这样写:

Short shortValue = (short)12345; System.out.println(Objects.equals(shortValue, (short)12345)); // true Integer intValue = 12345; System.out.println(Objects.equals(intValue, 12345)); // true Long longValue = 12345L; System.out.println(Objects.equals(longValue, 12345L)); // true

2)借助开发工具或插件,及早地发现数据类型不匹配问题

在 Eclipse 的问题窗口中,我们会看到这样的提示:

Unlikely argument type for equals(): int seems to be unrelated to Short Unlikely argument type for equals(): int seems to be unrelated to Long

3)进行常规性单元测试,尽量把问题发现在研发阶段

“勿以善小而不为”,不要因为改动很小就不需要进行单元测试了,往往 Bug  都出现在自己过度自信的代码中。像这种问题,只要进行一次单元测试,是完全可以发现问题的。

注意:进行必要单元测试,适用于以下所有案例,所以下文不再累述。

2、三元表达式拆包

三元表达式是 Java 编码中的一个固定语法格式:

条件表达式?表达式1:表达式2

三元表达式的逻辑为:如果条件表达式成立,则执行表达式 1,否则执行表达式 2。

问题现象

boolean condition = false; Double value1 = 1.0D; Double value2 = 2.0D; Double value3 = null; Double result = condition ? value1 * value2 : value3; // 抛出空指针异常

当条件表达式 condition 等于 false 时,直接把 Double 对象 value3 赋值给 Double 对象  result,按道理没有任何问题,为什么会抛出空指针异常?

问题分析

通过反编译代码,我们得到语句:

Double result = condition ? value1 * value2 : value3;

的字节码指令如下:

iload_1 [condition] ifeq 33 aload_2 [value1] invokevirtual java.lang.Double.doubleValue() : double [24] aload_3 [value2] invokevirtual java.lang.Double.doubleValue() : double [24] dmul goto 38 aload 4 [value3] invokevirtual java.lang.Double.doubleValue() : double [24] invokestatic java.lang.Double.valueOf(double) : java.lang.Double [16] astore 5 [result]

在第 9 行,加载 Double 对象 value 3 到操作数栈中;在第 10 行,调用 Double 对象 value 3 的 doubleValue  方法。这个时候,由于 value 3 是空对象 null,调用 doubleValue 方法必然抛出抛出空指针异常。但是,为什么要把空对象 value 3  转化为基础数据类型 double 呢?

查阅相关资料,得到三元表达式的类型转化规则:

根据规则分析,表达式 1(value1 * value2)的类型为基础数据类型 double,表达式 2(value 3)的类型为包装数据类型  Double,根据三元表达式的类型转化规则判断,最终的表达式类型为基础数据类型 double。所以,当条件表达式 condition 为 false  时,需要把空 Double 对象 value 3 转化为基础数据类型 double,于是就调用了 value 3 的 doubleValue  方法进行拆包,当然会抛出空指针异常。

避坑方法

1)尽量避免使用三元表达式,可以采用 if-else 语句代替

如果三元表达式中有包装数据类型的算术计算,可以考虑利用 if-else 语句代替。改写代码如下:

if (condition) {   result = value1 * value2; } else {   result = value3; }

2)尽量使用基本数据类型,避免包装数据类型的拆装包

如果在三元表达式中有算术计算,尽量使用基本数据类型,避免包装数据类型的拆装包。改写代码如下:

boolean condition = false; double value1 = 1.0D; double value2 = 2.0D; double value3 = 3.0D; double result = condition ? value1 * value2 : value3;

3、泛型对象赋值

Java 泛型是 JDK 1.5 中引入的一个新特性,其本质是参数化类型,即把数据类型做为一个参数使用。

问题现象

在做用户数据分页查询时,因为笔误编写了如下代码:

1)PageDataVO.java

/** 分页数据VO类 */ @Getter @Setter @ToString @NoArgsConstructor @AllArgsConstructor public class PageDataVO<T> {   /** 总共数量 */   private Long totalCount;   /** 数据列表 */   private List<T> dataList; }

2)UserDAO.java

/** 用户DAO接口 */ @Mapper public interface UserDAO {   /** 统计用户数量 */   public Long countUser(@Param("query") UserQueryVO query);   /** 查询用户信息 */   public List<UserDO> queryUser(@Param("query") UserQueryVO query);}

3)UserService.java

/** 用户服务类 */@Service public class UserService {   /** 用户DAO */   @Autowired   private UserDAO userDAO;   /** 查询用户信息 */   public PageDataVO<UserVO> queryUser(UserQueryVO query) {     List<UserDO> dataList = null;     Long totalCount = userDAO.countUser(query);     if (Objects.nonNull(totalCount) && totalCount.compareTo(0L) > 0) {       dataList = userDAO.queryUser(query);     }     return new PageDataVO(totalCount, dataList);   } }

以上代码没有任何编译问题,但是却把 UserDO 中一些涉密字段返回给前端。细心的读者可能已经发现了,在 UserService 类的 queryUser  方法的语句 return new PageDataVO(totalCount, dataList); 中,我们把 List对象  dataList 赋值给了 PageDataVO的 List字段 dataList。

问题是:为什么开发工具不报编译错误啦?

问题分析

由于历史原因,参数化类型和原始类型需要兼容。我们以 ArrayList 举例子,来看看如何兼容的。

以前的写法:

ArrayList list = new ArrayList();

现在的写法:

ArrayList<String> list = new ArrayList<String>();

考虑到与以前的代码兼容,各种对象引用之间传值,必然会出现以下的情况:

// 第一种情况 ArrayList list1 = new ArrayList<String>(); // 第二种情况 ArrayList<String> list2 = new ArrayList();

所以,Java 编译器对以上两种类型进行了兼容,不会出现编译错误,但会出现编译告警。但是,我的开发工具在编译时真没出现过告警。

再来分析我们遇到的问题,实际上同时命中了两种情况:

最终的效果就是:我们神奇地把 List对象赋值给了 List

问题的根源就是:我们在初始化 PageDataVO 对象时,没有要求强制进行类型检查。

避坑方法

1)在初始化泛型对象时,推荐使用 diamond 语法

在《 Java 开发手册》中,有这么一条推荐规则:

【推荐】集合泛型定义时,在 JDK7 及以上,使用 diamond 语法或全省略。

说明:菱形泛型,即 diamond,直接使用<>来指代前边已经指定的类型。

正例:

// <> diamond 方式 HashMap<String, String> userCache = new HashMap<>(16); // 全省略方式ArrayList<User> users = new ArrayList(10);

其实,初始化泛型对象时,全省略是不推荐的。这样会避免类型检查,从而造成上面的问题。

在初始化泛型对象时,推荐使用 diamond 语法,代码如下:

return new PageDataVO<>(totalCount, dataList);

现在,在 Eclipse 的问题窗口中,我们会看到这样的错误:

Cannot infer type arguments for PageDataVO<>

于是,我们就知道忘记把 List对象转化为 List对象了。

4、泛型属性拷贝

Spring 的 BeanUtils.copyProperties 方法,是一个很好用的属性拷贝工具方法。

问题现象

根据数据库开发规范,数据库表格必须包含 id,gmt_create,gmt_modified 三个字段。其中,id 这个字段,可能根据数据量不同,采用  int 或 long 类型。

首先,定义了一个 BaseDO 基类:

/** 基础DO类 */ @Getter @Setter @ToString public class BaseDO<T> {   private T id;   private Date gmtCreate;   private Date gmtModified;}

针对 user 表,定义了一个 UserDO 类:

/** 用户DO */ @Getter @Setter @ToString public static class UserDO extends BaseDO<Long> {       private String name;   private String description; }

对于查询接口,定义了一个 UserVO 类:

/** 用户VO类 */ @Getter @Setter @ToString public static class UserVO {     private Long id;     private String name;     private String description; }

实现查询用户服务接口,实现代码如下:

/** 用户服务类 */ @Service public class UserService {          /** 用户DAO */         @Autowired         private UserDAO userDAO;      /** 查询用户 */           public List<UserVO> queryUser(UserQueryVO query) {                   // 查询用户信息                   List<UserDO> userDOList = userDAO.queryUser(query);                   if (CollectionUtils.isEmpty()) {                             return Collections.emptyList();              }               // 转化用户列表                  List<UserVO> userVOList = new ArrayList<>(userDOList.size());            for (UserDO userDO : userDOList) {                              UserVO userVO = new UserVO();                          BeanUtils.copyProperties(userDO, userVO);                          userVOList.add(userVO);                     }         // 返回用户列表        return userVOList;            } }

通过测试,我们会发现一个问题&mdash;&mdash;调用查询用户服务接口,用户 ID 的值并没有返回。

[{"description":"This is a tester.","name":"tester"},...]

问题分析

通过 Debug 模式运行,进入到 BeanUtils.copyProperties 工具方法内部,得到以下内容:

编写Java的坑有哪些

原来,UserDO 类的 getId 方法返回类型不是 Long 类型,而是被泛型还原成了 Object 类型。而下面的  ClassUtils.isAssignable 工具方法,判断是否能够把 Object 类型赋值给 Long  类型,当然会返回false导致不能进行属性拷贝。

为什么作者不考虑"先获取属性值,再判断能否赋值”?建议代码如下:

Object value = readMethod.invoke(source); if (Objects.nonNull(value) &&  ClassUtils.isAssignable(writeMethod.getParameterTypes()[0], value.getClass())) {        ... // 赋值相关代码 }

避坑方法

1)不要盲目地相信第三方工具包,任何工具包都有可能存在问题

在 Java 中,存在很多第三方工具包,比如:Apache 的 commons-lang3、commons-collections,Google 的  guava&hellip;&hellip;都是很好用的第三方工具包。但是,不要盲目地相信第三方工具包,任何工具包都有可能存在问题。

2)如果需要拷贝的属性较少,可以手动编码进行属性拷贝

用 BeanUtils.copyProperties  反射拷贝属性,主要优点是节省了代码量,主要缺点是导致程序性能下降。所以,如果需要拷贝的属性较少,可以手动编码进行属性拷贝。

5、Set 对象排重

在 Java 语言中,Set 数据结构可以用于对象排重,常见的 Set 类有 HashSet、LinkedHashSet 等。

问题现象

编写了一个城市辅助类,从 CSV 文件中读取城市数据:

/** 城市辅助类 */ @Slf4j public class CityHelper {     /** 读取城市 */     public static Collection<City> readCities(String fileName) {         try (FileInputStream stream = new FileInputStream(fileName);             InputStreamReader reader = new InputStreamReader(stream, "GBK");             CSVParser parser = new CSVParser(reader, CSVFormat.DEFAULT.withHeader())) {             Set<City> citySet = new HashSet<>(1024);             Iterator<CSVRecord> iterator = parser.iterator();             while (iterator.hasNext()) {                 citySet.add(parseCity(iterator.next()));             }             return citySet;         } catch (IOException e) {             log.warn("读取所有城市异常", e);         }         return Collections.emptyList();     }      /** 解析城市 */     private static City parseCity(CSVRecord record) {         City city = new City();         city.setCode(record.get(0));         city.setName(record.get(1));         return city;     }      /** 城市类 */     @Getter     @Setter     @ToString     private static class City {         /** 城市编码 */         private String code;         /** 城市名称 */         private String name;     } }

代码中使用 HashSet 数据结构,目的是为了避免城市数据重复,对读取的城市数据进行强制排重。

当输入文件内容如下时:

编码,名称 010,北京 020,广州 010,北京

解析后的 JSON 结果如下:

[{"code":"010","name":"北京"},{"code":"020","name":"广州"},{"code":"010","name":"北京"}]

但是,并没有对城市“北京”进行排重。

问题分析

当向集合 Set 中增加对象时,首先集合计算要增加对象的  hashCode,根据该值来得到一个位置用来存放当前对象。如在该位置没有一个对象存在的话,那么集合 Set  认为该对象在集合中不存在,直接增加进去。如果在该位置有一个对象存在的话,接着将准备增加到集合中的对象与该位置上的对象进行 equals 方法比较:如果该  equals 方法返回 false,那么集合认为集合中不存在该对象,就把该对象放在这个对象之后;如果 equals 方法返回  true,那么就认为集合中已经存在该对象了,就不会再将该对象增加到集合中了。所以,在哈希表中判断两个元素是否重复要使用到 hashCode 方法和 equals  方法。hashCode 方法决定数据在表中的存储位置,而 equals 方法判断表中是否存在相同的数据。

分析上面的问题,由于没有重写 City 类的 hashCode 方法和 equals 方法,就会采用 Object 类的 hashCode 方法和  equals 方法。其实现如下:

public native int hashCode(); public boolean equals(Object obj) {     return (this == obj); }

可以看出:Object 类的 hashCode 方法是一个本地方法,返回的是对象地址;Object 类的 equals  方法只比较对象是否相等。所以,对于两条完全一样的北京数据,由于在解析时初始化了不同的 City 对象,导致 hashCode 方法和 equals  方法值都不一样,必然被 Set 认为是不同的对象,所以没有进行排重。

那么,我们就重写把 City 类的 hashCode 方法和 equals 方法,代码如下:

/** 城市类 */ @Getter @Setter @ToString private static class City {     /** 城市编码 */     private String code;     /** 城市名称 */     private String name;      /** 判断相等 */     @Override     public boolean equals(Object obj) {         if (obj == this) {             return true;         }         if (Objects.isNull(obj)) {             return false;         }         if (obj.getClass() != this.getClass()) {             return false;         }         return Objects.equals(this.code, ((City)obj).code);     }      /** 哈希编码 */     @Override     public int hashCode() {         return Objects.hashCode(this.code);     } }

重新支持测试程序,解析后的 JSON 结果如下:

[{"code":"010","name":"北京"},{"code":"020","name":"广州"}]

结果正确,已经对城市“北京”进行排重。

避坑方法

1)当确定数据唯一时,可以使用 List 代替 Set

当确定解析的城市数据唯一时,就没有必要进行排重操作,可以直接使用 List 来存储。

List<City> citySet = new ArrayList<>(1024); Iterator<CSVRecord> iterator = parser.iterator(); while (iterator.hasNext()) {     citySet.add(parseCity(iterator.next())); } return citySet;

2)当确定数据不唯一时,可以使用 Map 代替 Set

当确定解析的城市数据不唯一时,需要安装城市名称进行排重操作,可以直接使用 Map 进行存储。为什么不建议实现 City 类的 hashCode  方法,再采用 HashSet 来实现排重呢?首先,不希望把业务逻辑放在模型 DO 类中;其次,把排重字段放在代码中,便于代码的阅读、理解和维护。

Map<String, City> cityMap = new HashMap<>(1024); Iterator<CSVRecord> iterator = parser.iterator(); while (iterator.hasNext()) {     City city = parseCity(iterator.next());     cityMap.put(city.getCode(), city); } return cityMap.values();

3)遵循 Java 语言规范,重写 hashCode 方法和 equals 方法

不重写 hashCode 方法和 equals 方法的自定义类不应该在 Set 中使用。

6、公有方法代理

SpringCGLIB 代理生成的代理类是一个继承被代理类,通过重写被代理类中的非 final 的方法实现代理。所以,SpringCGLIB  代理的类不能是 final 类,代理的方法也不能是 final 方法,这是由继承机制限制的。

问题现象

这里举例一个简单的例子,只有超级用户才有删除公司的权限,并且所有服务函数被 AOP 拦截处理异常。例子代码如下:

1)UserService.java

/** 用户服务类 */ @Service public class UserService {     /** 超级用户 */     private User superUser;      /** 设置超级用户 */     public void setSuperUser(User superUser) {         this.superUser = superUser;     }      /** 获取超级用户 */     public final User getSuperUser() {         return this.superUser;     } }

2)CompanyService.java

/** 公司服务类 */ @Service public class CompanyService {     /** 公司DAO */     @Autowired     private CompanyDAO companyDAO;     /** 用户服务 */     @Autowired     private UserService userService;      /** 删除公司 */     public void deleteCompany(Long companyId, Long operatorId) {         // 设置超级用户         userService.setSuperUser(new User(0L, "admin", "超级用户"));          // 验证超级用户         if (!Objects.equals(operatorId, userService.getSuperUser().getId())) {             throw new ExampleException("只有超级用户才能删除公司");         }          // 删除公司信息         companyDAO.delete(companyId, operatorId);     } }

当我们调用 CompanyService 的 deleteCompany 方法时,居然也抛出空指针异常  (NullPointerException),因为调用 UserService 类的 getSuperUser 方法获取的超级用户为 null。但是,我们在  CompanyService 类的 deleteCompany 方法中,每次都通过 UserService 类的 setSuperUser  方法强制指定了超级用户,按道理通过 UserService 类的 getSuperUser 方法获取到的超级用户不应该为 null。其实,这个问题也是由 AOP  代理导致的。

问题分析

使用 SpringCGLIB 代理类时,Spring  会创建一个名为UserService$$EnhancerBySpringCGLIB$$???????? 的代理类。反编译这个代理类,得到以下主要代码:

public class UserService$$EnhancerBySpringCGLIB$$a2c3b345 extends UserService implements SpringProxy, Advised, Factory {     ......     public final void setSuperUser(User var1) {         MethodInterceptor var10000 = this.CGLIB$CALLBACK_0;         if (var10000 == null) {             CGLIB$BIND_CALLBACKS(this);             var10000 = this.CGLIB$CALLBACK_0;         }          if (var10000 != null) {             var10000.intercept(this, CGLIB$setSuperUser$0$Method, new Object[]{var1}, CGLIB$setSuperUser$0$Proxy);         } else {             super.setSuperUser(var1);         }     }     ...... }

可以看出,这个代理类继承了 UserService 类,只代理了 setSuperUser 方法,但是没有代理 getSuperUser  方法。所以,当我们调用 setSuperUser 方法时,设置的是原始对象实例的 superUser 字段值;而当我们调用 getSuperUser  方法时,获取的是代理对象实例的 superUser 字段值。如果把这两个方法的 final 修饰符互换,同样存在获取超级用户为 null 的问题。

避坑方法

1)严格遵循 CGLIB 代理规范,被代理的类和方法不要加 final 修饰符

严格遵循 CGLIB 代理规范,被代理的类和方法不要加 final  修饰符,避免动态代理操作对象实例不同(原始对象实例和代理对象实例),从而导致数据不一致或空指针问题。

2)缩小 CGLIB 代理类的范围,能不用被代理的类就不要被代理

缩小 CGLIB 代理类的范围,能不用被代理的类就不要被代理,即可以节省内存开销,又可以提高函数调用效率。

7、公有字段代理

在 fastjson 强制升级到 1.2.60 时踩过一个坑,作者为了开发快速,在 ParseConfig 中定义了:

public class ParseConfig {     public final SymbolTable symbolTable = new SymbolTable(4096);     ...... }

在我们的项目中继承了该类,同时又被 AOP 动态代理了,于是一行代码引起了一场“血案”。

问题现象

仍然使用上章的例子,但是把获取、设置方法删除,定义了一个公有字段。例子代码如下:

1)UserService.java

/** 用户服务类 */ @Service public class UserService {     /** 超级用户 */     public final User superUser = new User(0L, "admin", "超级用户");     ...... }

2)CompanyService.java

/** 公司服务类 */ @Service public class CompanyService {     /** 公司DAO */     @Autowired     private CompanyDAO companyDAO;     /** 用户服务 */     @Autowired     private UserService userService;      /** 删除公司 */     public void deleteCompany(Long companyId, Long operatorId) {         // 验证超级用户         if (!Objects.equals(operatorId, userService.superUser.getId())) {             throw new ExampleException("只有超级用户才能删除公司");         }          // 删除公司信息         companyDAO.delete(companyId, operatorId);     } }

当我们调用 CompanyService 的 deleteCompany 方法时,居然抛出空指针异常  (NullPointerException)。经过调试打印,发现是 UserService 的 superUser 变量为  null。如果把代理删除,就不会出现空指针异常,说明这个问题是由 AOP 代理导致的。

问题分析

使用 SpringCGLIB 代理类时,Spring  会创建一个名为UserService$$EnhancerBySpringCGLIB$$???????? 的代理类。这个代理类继承了 UserService  类,并覆盖了 UserService 类中的所有非 final 的 public 的方法。但是,这个代理类并不调用 super  基类的方法;相反,它会创建的一个成员 userService 并指向原始的 UserService 类对象实例。现在,内存中存在两个对象实例:一个是原始的  UserService 对象实例,另一个指向 UserService 的代理对象实例。这个代理类只是一个虚拟代理,它继承了 UserService  类,并且具有与 UserService 相同的字段,但是它从来不会去初始化和使用它们。所以,一但通过这个代理类对象实例获取公有成员变量时,将返回一个默认值  null。


编写Java的坑有哪些

避坑方法

1)当确定字段不可变时,可以定义为公有静态常量

当确定字段不可变时,可以定义为公有静态常量,并用类名称 + 字段名称访问。类名称 + 字段名称访问公有静态常量,与类实例的动态代理无关。

2)当确定字段不可变时,可以定义为私有成员变量

当确定字段不可变时,可以定义为私有成员变量,提供一个公有 Getter 方法获取该变量值。当该类实例被动态代理时,代理方法会调用被代理的 Getter  方法,从而返回被代理类的成员变量值。

3)遵循 JavaBean 编码规范,不要定义公有成员变量

遵循 JavaBean 编码规范,不要定义公有成员变量。JavaBean 规范如下:

到此,相信大家对“编写Java的坑有哪些”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

推荐阅读:
  1. Java CPP的坑有哪些
  2. Java应该避免的坑有哪些

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

java

上一篇:怎么进行清除alert log

下一篇:如何进行linux sudo权限配置

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》