- 博客(117)
- 收藏
- 关注
RSS订阅原创 34 | 到底可不可以使用join？
在形式上，这个过程就跟我们写程序时的嵌套查询类似，并且可以用上被驱动表的索引，所以我们称之为“Index Nested-Loop Join”，简称 NLJ。由于 join_buffer 是以无序数组的方式组织的，因此对表 t2 中的每一行，都要做 100 次判断，总共需要在内存中做的判断次数是：100*1000=10 万次。假设被驱动表的行数是 M。这还只是两个小表，如果 t1 和 t2 都是 10 万行的表（当然了，这也还是属于小表的范围），就要扫描 100 亿行，这个算法看上去太“笨重”了。
2024-03-22 16:01:52
772
原创 19 | 为什么我只查一行的语句，也执行这么慢？
如果我把这个 slow log 的截图再往下拉一点，你可以看到下一个语句，select * from t where id=1 lock in share mode，执行时扫描行数也是 1 行，执行时间是 0.2 毫秒。今天，我就跟你聊聊这个有趣的话题，看看什么情况下，会出现这个现象。需要说明的是，如果 MySQL 数据库本身就有很大的压力，导致数据库服务器 CPU 占用率很高或 ioutil（IO 利用率）很高，这种情况下所有语句的执行都有可能变慢，不属于我们今天的讨论范围。
2024-03-21 11:27:34
877
原创 18 | 为什么这些SQL语句逻辑相同，性能却差异巨大？
按照下面这个写法，优化器就能按照我们预期的，用上 t_modified 索引的快速定位能力了。在这个例子里，放弃了树搜索功能，优化器可以选择遍历主键索引，也可以选择遍历索引 t_modified，优化器对比索引大小后发现，索引 t_modified 更小，遍历这个索引比遍历主键索引来得更快。参照前面的两个例子，你肯定就想到了，字符集 utf8mb4 是 utf8 的超集，所以当这两个类型的字符串在做比较的时候，MySQL 内部的操作是，先把 utf8 字符串转成 utf8mb4 字符集，再做比较。
2024-03-19 11:41:10
821
原创 16 | “order by”是怎么工作的？
也就是说，在我们这个例子里，只需要扫描 1000 次。需要说明的是，最后的“结果集”是一个逻辑概念，实际上 MySQL 服务端从排序后的 sort_buffer 中依次取出 id，然后到原表查到 city、name 和 age 这三个字段的结果，不需要在服务端再耗费内存存储结果，是直接返回给客户端的。在这个索引里面，我们依然可以用树搜索的方式定位到第一个满足 city='杭州’的记录，并且额外确保了，接下来按顺序取“下一条记录”的遍历过程中，只要 city 的值是杭州，name 的值就一定是有序的。
2024-03-15 14:47:00
816
原创 13 | 为什么表数据删掉一半，表文件大小不变？
如果我们把表 B 作为临时表，数据从表 A 导入表 B 的操作完成后，用表 B 替换 A，从效果上看，就起到了收缩表 A 空间的作用。记录的复用，只限于符合范围条件的数据。但是，我们遇到的更多的删除数据的场景是删除某些行，这时就遇到了我们文章开头的问题：表中的数据被删除了，但是表空间却没有被回收。现在，你已经知道了 InnoDB 的数据是按页存储的，那么如果我们删掉了一个数据页上的所有记录，会怎么样？经常会有同学来问我，我的数据库占用空间太大，我把一个最大的表删掉了一半的数据，怎么表文件的大小还是没变？
2024-03-13 09:39:51
710
原创 11 | 怎么给字符串字段加索引？
但是，对于这个查询语句来说，如果你定义的 index2 不是 email(6) 而是 email(7），也就是说取 email 字段的前 7 个字节来构建索引的话，即满足前缀’zhangss’的记录只有一个，也能够直接查到 ID2，只扫描一行就结束了。首先，它们的相同点是，都不支持范围查询。即使你将 index2 的定义修改为 email(18) 的前缀索引，这时候虽然 index2 已经包含了所有的信息，但 InnoDB 还是要回到 id 索引再查一下，因为系统并不确定前缀索引的定义是否截断了完整信息。
2024-03-12 15:40:31
1044
原创 10 | MySQL为什么有时候会选错索引？
当然，这种修改并不是通用的优化手段，只是刚好在这个语句里面有 limit 1，，因此如果有满足条件的记录， order by b limit 1 和 order by b,a limit 1 都会返回 b 是最小的那一行，逻辑上一致，才可以这么做。显然，一个索引上不同的值越多，这个索引的区分度就越好。之前优化器选择使用索引 b，是因为它认为使用索引 b 可以避免排序（b 本身是索引，已经是有序的了，如果选择索引 b 的话，不需要再做排序，只需要遍历），所以即使扫描行数多，也判定为代价更小。
2024-03-09 17:59:16
989
原创 08 | 事务到底是隔离的还是不隔离的？
我在第 3 篇文章和你讲事务隔离级别的时候提到过，如果是可重复读隔离级别，事务 T 启动的时候会创建一个视图 read-view，之后事务 T 执行期间，即使有其他事务修改了数据，事务 T 看到的仍然跟在启动时看到的一样。因为之后的更新，生成的版本一定属于上面的 2 或者 3(a) 的情况，而对它来说，这些新的数据版本是不存在的，所以这个事务的快照，就是“静态”的了。可是，我平时的事务执行起来很快啊。因此，一个事务只需要在启动的时候声明说，“以我启动的时刻为准，如果一个数据版本是在我启动之前生成的，就认；
2024-03-08 16:24:51
936
原创 07 | 行锁功过：怎么减少行锁对性能的影响？
根据上面的分析，你会发现如果并发能够控制住，比如同一行同时最多只有 10 个线程在更新，那么死锁检测的成本很低，就不会出现这个问题。在 InnoDB 中，innodb_lock_wait_timeout 的默认值是 50s，意味着如果采用第一个策略，当出现死锁以后，第一个被锁住的线程要过 50s 才会超时退出，然后其他线程才有可能继续执行。但是这种操作本身带有一定的风险，因为业务设计的时候一般不会把死锁当做一个严重错误，毕竟出现死锁了，就回滚，然后通过业务重试一般就没问题了，这是业务无损的。
2024-03-08 11:26:46
733
原创 05 | 深入浅出索引（下）
也就是说，在这个查询里面，索引 k 已经“覆盖了”我们的查询需求，我们称为覆盖索引。需要注意的是，在引擎内部使用覆盖索引在索引 k 上其实读了三个记录，R3~R5（对应的索引 k 上的记录项），但是对于 MySQL 的 Server 层来说，它就是找引擎拿到了两条记录，因此 MySQL 认为扫描行数是 2。而 MySQL 5.6 引入的索引下推优化（index condition pushdown)， 可以在索引遍历过程中，对索引中包含的字段先做判断，直接过滤掉不满足条件的记录，减少回表次数。
2024-03-07 15:38:51
684
原创 04 |深入浅出索引（上）
你要查身份证号在[ID_card_X, ID_card_Y]区间的 User，可以先用二分法找到 ID_card_X（如果不存在 ID_card_X，就找到大于 ID_card_X 的第一个 User），然后向右遍历，直到查到第一个大于 ID_card_Y 的身份证号，退出循环。二叉搜索树的特点是：父节点左子树所有结点的值小于父节点的值，右子树所有结点的值大于父节点的值。需要注意的是，图中四个 ID_card_n 的值并不是递增的，这样做的好处是增加新的 User 时速度会很快，只需要往后追加。
2024-03-07 13:56:26
480
原创 03 | 事务隔离：为什么你改了我还看不见？
当前值是 4，但是在查询这条记录的时候，不同时刻启动的事务会有不同的 read-view。转账过程具体到程序里会有一系列的操作，比如查询余额、做加减法、更新余额等，这些操作必须保证是一体的，不然等程序查完之后，还没做减法之前，你这 100 块钱，完全可以借着这个时间差再查一次，然后再给另外一个朋友转账，如果银行这么整，不就乱了么？今天的文章里，我将会以 InnoDB 为例，剖析 MySQL 在事务支持方面的特定实现，并基于原理给出相应的实践建议，希望这些案例能加深你对 MySQL 事务原理的理解。
2024-03-06 17:52:46
651
原创 02 | 日志系统：一条SQL更新语句是如何执行的？
当你需要扩容的时候，也就是需要再多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用 binlog 来实现的，这个“不一致”就会导致你的线上出现主从数据库不一致的情况。但如果赊账的人多了，粉板总会有记不下的时候，这个时候掌柜一定还有一个专门记录赊账的账本。而粉板和账本配合的整个过程，其实就是 MySQL 里经常说到的 WAL 技术，WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
2024-03-05 17:11:09
649
原创 01 | 基础架构：一条SQL查询语句是如何执行的？
不同存储引擎的表数据存取方式不同，支持的功能也不同，在后面的文章中，我们会讨论到引擎的选择。比如，一个系统配置表，那这张表上的查询才适合使用查询缓存。开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误，如下所示 (在工程实现上，如果命中查询缓存，会在查询缓存返回结果的时候，做权限验证。连接命令中的 mysql 是客户端工具，用来跟服务端建立连接在完成经典的 TCP 握手后，连接器就要开始认证你的身份，这个时候用的就是你输入的用户名和密码。
2024-03-05 15:25:06
547
原创 Spring Test 常见错误
而 classPath 更为普适些，而一旦你按上述方式修正后，你会发现它加载的资源已经不再是 ServletContextResource，而是和应用程序一样的 ClassPathResource，这样自然可以加载到了。当然或许这些所谓的常用，你仍然没有使用，例如对于 Spring Data 的使用，，有的项目确实用不到。那么这一讲，我们聊聊 Spring Test，相信你肯定绕不开对它的使用，除非你不使用 Spring 来开发程序，或者你使用了 Spring 但是你不写测试。测试这个接口，一切符合预期。
2024-03-05 11:34:15
790
原创 Spring Rest Template 常见错误
在不使用 Spring 之前，我们一般都是直接使用 Apache HttpClient 和 Ok HttpClient 等，而一旦你引入 Spring，你就有了一个更好的选择，这就是我们这一讲的主角 RestTemplate。上述代码看起来比较复杂，实际上功能很简单：根据当前要提交的 Body 内容,遍历当前支持的所有编解码器，如果找到合适的编解码器，就使用它来完成 Body 的转化。看到这里，你可能会豁然开朗。可以看出，当我们使用的 Body 是一个 HashMap 时，是可以完成 JSON 序列化的。
2024-03-04 17:43:31
941
原创 Spring 事务常见错误（下）
所以到这里，问题也就清楚了，Spring 默认的事务传播属性为 REQUIRED，如我们之前介绍的，它的含义是：如果本来有事务，则加入该事务，如果没有事务，则创建新的事务，因而内外两层事务都处于同一个事务中。在前面的案例中，我们完成了学生注册功能和课程注册功能。结合我们的伪代码示例，因为在 saveStudent() 上声明了一个外部的事务，就已经存在一个事务了，在 propagation 值为默认的 REQUIRED 的情况下，regCourse() 就会加入到已有的事务中，两个方法共用一个事务。
2024-03-04 16:36:17
1077
原创 Spring 事务常见错误（上）
不过需要额外补充的是，我们调用这个加了事务注解的方法，必须是调用被 Spring AOP 代理过的方法，也就是不能通过类的内部调用或者通过 this 的方式调用。在我们的错误案例示范中，我们统一使用更为方便的注解式方式。而在父类的 rollbackOn() 中，我们发现了一个重要的线索，只有在异常类型为 RuntimeException 或者 Error 的时候才会返回 true，此时，会触发 completeTransactionAfterThrowing 方法中的 rollback 操作，事务被回滚。
2024-03-01 14:52:11
1070
原创 Spring Data 常见错误
没错，这是一个极度简化的案例，我们的学习目的是举一反三。要解决这个问题，非常简单，就是检查自己所有的数据操作，是否使用了相同的 RedisTemplate，就是相同，也要检查所指定的各种 Serializer 是否完全一致，否则就会出现各式各样的错误。首先，我们需要认清一个现实：我们不可能直接将数据存取到 Redis 中，毕竟一些数据是一个对象型，例如 String，甚至是一些自定义对象。当使用 Spring Data Redis 时，我们有时候会在项目升级的过程中，发现存储后的数据有读取不到的情况；
2024-03-01 13:54:07
517
原创 Spring Exception 常见错误
同样，当第一次请求发生时，DispatcherServlet 中的 initHandlerMappings() 将会获取所有注册到 Spring 的 HandlerMapping 类型的实例，而 SimpleUrlHandlerMapping 恰好实现了 HandlerMapping 接口，这些 SimpleUrlHandlerMapping 类型的实例则会被写入到类成员变量 handlerMappings 中。Spring 提供了一套健全的异常处理框架，以便我们在开发应用的时候对异常进行处理。
2024-02-29 16:07:47
760
原创 Spring Web 过滤器使用常见错误（上）
而在实际生产过程中，如果我们需要构建的过滤器是针对全局路径有效，且没有任何特殊需求（主要是指对 Servlet 3.0 的一些异步特性支持），那么你完全可以直接使用 Filter 接口（或者继承 Spring 对 Filter 接口的包装类 OncePerRequestFilter），并使用 @Component 将其包装为 Spring 中的普通 Bean，也是可以达到预期的需求。这个过程就不再一一细讲了。这个问题出现的根源往往在于“不小心”，但是要理解这个问题呈现的现象，就必须对过滤器的流程有所了解。
2024-02-28 17:54:26
1277
原创 Spring Web 参数验证常见错误
通过解析，我们会发现，在很多场景下，我们不一定要寄希望于搜索引擎去区别，只需要稍微研读下代码，反而更容易理解。通过前面两个案例的填坑，我们一般都能让参数校验生效起来，但是校验本身有时候是一个无止境的完善过程，校验本身已经生效，但是否完美匹配我们所有苛刻的要求是另外一个容易疏忽的地方。看完上面的一些案例，我们会发现，这些错误的直接结果都是校验完全失败或者部分失败，并不会造成严重的后果,但是就像本讲开头所讲的那样，这些错误会影响我们的使用体验，所以我们还是需要去规避这些错误，把校验做强最好！
2024-02-27 11:48:11
694
原创 Spring Web Body 转化常见错误
2.在非 Spring Boot 程序中，JSON 等编解码器不见得是内置好的，需要添加相关的 JAR 才能自动依赖上，而自动依赖的实现是通过检查 Class 是否存在来实现的：当依赖上相关的 JAR 后，关键的 Class 就存在了，响应的编解码器功能也就提供上了。3.不同的编解码器的实现（例如 JSON 工具 Jaskson 和 Gson）可能有一些细节上的不同，所以你一定要注意当依赖一个新的 JAR 时，是否会引起默认编解码器的改变，从而影响到一些局部行为的改变。那么它是如何工作起来的呢？
2024-02-06 11:14:46
1270
原创 Spring Web Header 解析常见错误
这里我解释一下，上述代码是先根据是否具有 Content-Type 头来决定返回的 MediaType，通过前面的分析它是一种特殊的 Header，在 Controller 层并没有被添加到 Header 中去，所以在这里只能根据返回的类型、请求的 Accept 等信息协商出最终用哪种 MediaType。这样的方式影响的是可以返回的 Media 类型，一旦设置，下面的方法就可以只返回一个指明的类型了。上，不管是结合代码还是常识，本案例的代码都不能获取到 myHeader 的所有值。
2024-02-05 16:34:40
1022
原创 Spring Web URL 解析常见错误
然而，从现实情况来看，在使用上，我们更多地是使用 Spring 来构建一个 Web 服务，所以从这节课开始，我们会重点解析在 Spring Web 开发中经常遇到的一些错误，帮助你规避这些问题。3. 任何一个参数，我们都需要考虑它是可选的还是必须的。很明显，若要判定一个参数是否是必须的，需要同时满足两个条件：条件 1 是 @RequestParam 指明了必须（即属性 required 为 true，实际上它也是默认值），条件 2 是要求 @RequestParam 标记的参数本身不是可选的。
2024-02-05 14:16:50
1570
原创 5分钟轻松了解一个HTTP请求的处理过程
在上述调用中，最终会进入 Spring Boot 的处理核心，即 DispatcherServlet 可以说，DispatcherServlet 是用来处理 HTTP 请求的中央调度入口程序，为每一个 Web 请求映射一个请求的处理执行体（API controller/method）。首先，解析 HTTP 请求。对于 Spring 而言，它本身并不提供通信层的支持，它是依赖于 Tomcat、Jetty 等容器来完成通信层的支持，例如当我们引入 Spring Boot 时，我们就间接依赖了 Tomcat。
2024-02-04 15:31:31
974
原创 Spring AOP 常见错误（下）
因此我们很容易看出问题所在：当前 ElectricService 中 charge() 的执行时间，包含了权限验证的时间，即包含了通过 @Around 增强的 checkAuthority() 执行的所有时间。当然，这些都是从日志直接观察出的现象。虽然鉴权失败，抛出了异常且 ElectricService.charge() 没有被调用，但是 logBeforeMethod() 的调用日志却被输出了，这将导致后期针对于 ElectricService.charge() 的调用数据统计严重失真。
2024-02-04 14:12:29
761
原创 Spring Bean 生命周期常见错误
显然 shutdown 方法未按照预期被执行了，这导致一个很有意思的 bug：在使用新的 Bean 生成方式之前，每一次宿舍管理服务被重启时，宿舍里所有的灯都不会被关闭。如何理解这个 bug?上述代码完整地展示了 Bean 初始化的三个关键步骤，createBeanInstance，populateBean，initializeBean，分别对应实例化 Bean，注入 Bean 依赖，以及初始化 Bean （例如执行 @PostConstruct 标记的方法 ）这三个功能，这也和上述时序图的流程相符。
2024-02-02 16:16:26
1087
原创 Spring Bean 依赖注入常见错误（下）
很明显，这两种装配集合的方式是不能同存的，结合本案例，当使用收集装配方式来装配时，能找到任何一个对应的 Bean，则返回，如果一个都没有找到，才会采用直接装配的方式。所以命名时，我们一定要注意。了解了这两种方式，我们再来思考这两种方式的关系：当同时满足这两种装配方式时，Spring 是如何处理的？从这可以看出，在解析 Value 字符串时，其实是有顺序的（查找的源是存在 CopyOnWriteArrayList 中，在启动时就被有序固定下来），一个一个“源”执行查找，在其中一个源找到后，就可以直接返回了。
2024-02-01 14:55:54
714
原创 Spring Bean 依赖注入常见错误（上）
看案例的话，当我们启动基于 Spring Boot 的应用程序时，会自动扫描我们的 Package，以找出直接或间接标记了 @Component 的 Bean 的定义（即 BeanDefinition）。但是，在实际使用中，我们仍然会出现各式各样的错误，而且都堪称经典。不过需要你注意的是，不是每一种条件的打破都满足实际需求，例如我们可以通过使用标记 @Primary 的方式来让被标记的候选者有更高优先级，从而避免报错，但是它并不一定符合业务需求，这就好比我们本身需要两种数据库都能使用，而不是顾此失彼。
2024-02-01 11:35:57
936
原创 Spring Bean 定义常见错误
此时扫描的是什么包？从上图可以看出，当 basePackages 为空时，扫描的包会是 declaringClass 所在的包，在本案例中，declaringClass 就是 Application.class，所以扫描的包其实就是它所在的包，即 com.spring.puzzle.class1.example1.application。例如，在程序开发过程中，有时候，一方面我们把一个类定义成 Bean，同时又觉得这个 Bean 的定义除了加了一些 Spring 注解外，并没有什么不同。
2024-01-31 17:51:40
997
原创 5分钟轻松了解Spring基础知识
当你最开始学习的时候，你可能困惑于为什么要用 Spring，而随着对 Spring 原理的深入探究和应用，你慢慢会发现，最大的收获其实还是对于这个困惑的理解。当你需要一个依赖的对象（房子）时，你直接把你的需求告诉 Spring（中介）就好了，它会帮你搞定这些依赖对象，按需创建它们，而无需你的任何额外操作。也是烦的不行，不是么？其实 AOP 并不神奇，结合刚才的 Bean（中介）公司来讲，假设我们判断出一个 Bean 需要“增强”了，我们直接让它从公司返回的时候，就使用一个代理对象作为返回不就可以了么？
2024-01-31 16:07:45
813
原创 java程序判等问题
一是，我们使用了 Lombok 的 @Data 标记了 Student，@Data 注解其实包含了 @EqualsAndHashCode 注解的作用，也就是默认情况下使用类型所有的字段参与到 equals 和 hashCode 方法的实现中。通过 equals 方法比较 p1 和 p2、p1 和 p3 均得到 false，原因正如刚才所说，我们并没有为 Point 类实现自定义的 equals 方法，Object 超类中的 equals 默认使用 == 判等，比较的是对象的引用。
2024-01-24 20:12:29
927
原创 Java 8 简化代码(2)
在接下来的讲述中，我会围绕订单场景，给出如何使用 Stream 的各种 API 完成订单的统计、搜索、查询等功能，和你一起学习 Stream 流式操作的各种方法。Key 是下单用户名，Value 是下单时间，一个用户可能多次下单，所以直接在这里进行了合并，只获取最近一次的下单时间。接下来，我们看看 flatMap 展开或者叫扁平化操作，相当于 map+flat，通过 map 把每一个元素替换为一个流，然后展开这个流。collect 是收集操作，对流进行终结（终止）操作，把流导出为我们需要的数据结构。
2024-01-19 17:51:27
877
原创 Java 8 简化代码(1)
Lambda 表达式可以帮我们用简短的代码实现方法的定义，给了我们复用代码的更多可能性。利用这个特性，我们可以把集合的投影、转换、过滤等操作抽象成通用的接口，然后通过 Lambda 表达式传入其具体实现，这也就是 Stream 操作。要通过 HashMap 实现一个缓存的操作，在 Java 8 之前我们可能会写出这样的 getProductAndCache 方法：先判断缓存中是否有值；简化后一行代码就可以实现这样的逻辑，更重要的是代码可读性更强了，通过方法名就可以知晓大概是在做什么事情。
2024-01-19 15:06:41
464
原创 应该怎样保存用户密码
第二，生成的盐和哈希后的密码拼在了一起：$是字段分隔符，其中第一个$后的 2a 代表算法版本，第二个$后的 10 是代价因子（默认是 10，代表 2 的 10 次方次哈希），第三个$后的 22 个字符是盐，再后面是摘要。所以，盐最好是随机的值，并且是全球唯一的，意味着全球不可能有现成的彩虹表给你用。CBC 模式，在解密或解密之前引入了 XOR 运算，第一个分组使用外部提供的初始化向量 IV，从第二个分组开始使用前一个分组的数据，这样即使明文是一样的，加密后的密文也是不同的，并且分组的顺序不能任意调换。
2024-01-18 17:46:53
831
原创 安全兜底：涉及钱时短信必须考虑防刷、限量和防重
但是，业务系统在实现资金操作时容易犯的错是，没有自始至终地使用一个订单号作为商户订单号，透传给三方支付接口。程序上线后，人是有休息时间的，但程序是一直运行着的，如果产生安全漏洞，就很可能在一夜之间爆发，被大量人利用导致大量的金钱损失。一般而言，这些接口都会有商户订单号的概念，对于相同的商户订单号，无法进行重复的资金处理，所以三方公司的接口可以实现唯一订单号的幂等处理。如果说，支付出现了重复扣款，我们可以给用户进行退款操作，但给用户付款的操作一旦出现重复付款，就很难把钱追回来了，所以更要小心。
2024-01-14 19:26:11
963
原创 【无标题】关于异常处理容易犯的错
第三，确保正确处理了线程池中任务的异常，如果任务通过 execute 提交，那么出现异常会导致线程退出，大量的异常会导致线程重复创建引起性能问题，我们应该尽可能确保任务不出异常，同时设置默认的未捕获异常处理程序来兜底；但，框架可以做兜底工作。通常情况下，生吞异常的原因，可能是不希望自己的方法抛出受检异常，只是为了把异常“处理掉”而捕获并生吞异常，也可能是想当然地认为异常并不重要或不可能产生。留下的日志是这样的，看完一脸茫然，只知道文件读取错误的文件名，至于为什么读取错误、是不存在还是没权限，完全不知道。
2024-01-13 20:51:22
924
原创 List列表操作中的坑
为此，我们使用 ObjectSizeCalculator 工具打印 ArrayList 和 HashMap 的内存占用，可以看到 ArrayList 占用内存 21M，而 HashMap 占用的内存达到了 72M，是 List 的三倍多。接下来，我们就一起分析下其中的坑。把三个字符串 1、2、3 构成的字符串数组，使用 Arrays.asList 转换为 List 后，将原始字符串数组的第二个字符修改为 4，然后为 List 增加一个字符串 5，最后数组和 List 会是怎样呢？
2024-01-11 17:40:11
1229
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人