java核心技术-（总结自杨晓峰-java核心技术36讲）

1. 谈谈你对java平台的理解

1. 首先是java最显著的两个特性，一次写入处处运行；还有垃圾收集器gc，gc能够对java内存进行管理回收，程序员不需要关心内存的分配和回收问题
2. 然后谈谈jre和jdk的区别，jre包含了jvm和java类库；jdk除了jvm和java类库，还包含了一些java工具集
3. 常见的垃圾收集器有：
   1. Serial GC：串行收集，垃圾回收时会阻塞工作线程
   2. Parallel GC：并行收集，多线程收集，停顿时间短，吞吐量高
   3. CMS：使用标记清除算法，多线程进行垃圾收集
   4. G1：吸收了CMS的优点，将堆划分为多个连续的区域，进行多线程收集。区域间采用复制算法，整体采用标记整理算法，避免内存碎片
4. 垃圾收集器特点
   • Serial收集器：串行运行；作用于新生代；复制算法；响应速度优先；适用于单CPU环境下的client模式。
   • ParNew收集器：并行运行；作用于新生代；复制算法；响应速度优先；多CPU环境Server模式下与CMS配合使用。
   • Parallel Scavenge收集器：并行运行；作用于新生代；复制算法；吞吐量优先；适用于后台运算而不需要太多交互的场景。
   • Serial Old收集器：串行运行；作用于老年代；标记-整理算法；响应速度优先；单CPU环境下的Client模式。
   • Parallel Old收集器：并行运行；作用于老年代；标记-整理算法；吞吐量优先；适用于后台运算而不需要太多交互的场景。
   • CMS收集器：并发运行；作用于老年代；标记-清除算法；响应速度优先；适用于互联网或B/S业务。
   • G1收集器：并发运行；可作用于新生代或老年代；标记-整理算法+复制算法；响应速度优先；面向服务端应用
5. .class文件在JVM中，进行的是解析或编译运行，JVM会对.class文件进行解析运行，同时JVM中存在JIT编译器，会对字节码文件进行编译预热，热点代码会编译优化成机器码执行

2. Exception和Error

1. Exception是异常，Error是错误，异常可以捕获处理，错误不需要处理
2. try-catch尽量包裹需要包裹的代码块，而不是全部
3. Exception捕获尽量细化，不要直接捕获Exception

3. 强引用、软引用、弱引用、幻象引用有什么区别

1. 强引用：最常见的引用，我们平时Object obj = new Object(),产生的引用都是强引用，只有在没有引用关系或obj = null的时候会被垃圾收集器收集
2. 软引用：当内存不够的时候，会优先回收软引用的对象，平时的用法和强引用一样
3. 弱引用：生命周期比软引用短，当垃圾收集器扫描到弱引用对象时，就会被回收
4. 虚引用（幻象引用）：无法通过引用获取对象属性，通常用来监视对象是否被回收

4. 谈谈Java反射机制，动态代理是基于什么原理？

1. 动态代理可以用反射实现，比如jdk自身提供的动态代理
2. 也可以利用字节码操作机制，cglib（基于asm）

5. Java提供了哪些IO方式？ NIO如何实现多路复用？

1. 由于nio实际上是同步非阻塞io，是一个线程在同步的进行事件处理，当一组channel处理完毕以后，去检查有没有又可以处理的channel。这也就是同步+非阻塞。同步，指每个准备好的channel处理是依次进行的，非阻塞，是指线程不会傻傻的等待读。只有当channel准备好后，才会进行。
2. 当每个channel所进行的都是耗时操作时，由于是同步操作，就会积压很多channel任务，从而完成影响。那么就需要对nio进行类似负载均衡的操作，如用线程池去进行管理读写，将channel分给其他的线程去执行，这样既充分利用了每一个线程，
3. nio不适合数据量太大交互的场景

6. IO和NIO拷贝的效率问题

1. 你需要理解用户态空间（User Space）和内核态空间（Kernel Space），这是操作系统层面的基本概念，操作系统内核、硬件驱动等运行在内核态空间，具有相对高的特权；而用户态空间，则是给普通应用和服务使用。

2. 当我们使用输入输出流进行读写时，实际上是进行了多次上下文切换，比如应用读取数据时，先在内核态将数据从磁盘读取到内核缓存，再切换到用户态将数据从内核缓存读取到用户缓存。所以，这种方式会带来一定的额外开销，可能会降低IO效率。
   

3. 而基于NIO transferTo的实现方式，在Linux和Unix上，则会使用到零拷贝技术，数据传输并不需要用户态参与，省去了上下文切换的开销和不必要的内存拷贝，进而可能提高应用拷贝性能。注意，transferTo不仅仅是可以用在文件拷贝中，与其类似的，例如读取磁盘文件，然后进行Socket发送，同样可以享受这种机制带来的性能和扩展性提高。
   

4. 零拷贝可以理解为内核态空间与磁盘之间的数据传输，不需要再经过用户态空间

7. 谈谈你知道的设计模式？请手动实现单例模式，Spring等框架中使用了哪些模式？

1. 设计模式可分为三种类型，创建型、结构型和行为型
2. 创建型例如：单例，工厂，建造者
3. 结构型例如：适配器，装饰器，代理模式等
4. 行为型例如：观察者，模板模式，命令模式
5. Spring中比较明显的有BeanFactory工厂模式，AOP代理模式，jdbcTemplate模板模式，各种监听器Listener，观察者模式

8. Java并发包提供了哪些并发工具类？

1. 提供了比synchronized更加高级的各种同步结构，包括CountDownLatch、CyclicBarrier、Semaphore等，可以实现更加丰富的多线程操作，比如利用Semaphore作为资源控制器，限制同时进行工作的线程数量。
2. 各种线程安全的容器，比如最常见的ConcurrentHashMap、有序的ConcunrrentSkipListMap，或者通过类似快照机制，实现线程安全的动态数组CopyOnWriteArrayList等。
3. 各种并发队列实现，如各种BlockedQueue实现，比较典型的ArrayBlockingQueue、 SynchorousQueue或针对特定场景的PriorityBlockingQueue等。
4. 强大的Executor框架，可以创建各种不同类型的线程池，调度任务运行等

9. 并发包中的ConcurrentLinkedQueue和LinkedBlockingQueue有什么区别？

1. Concurrent类型基于lock-free，在常见的多线程访问场景，一般可以提供较高吞吐量
2. 而LinkedBlockingQueue内部则是基于锁，并提供了BlockingQueue的等待性方法。
3. Concurrent类型没有类似CopyOnWrite之类容器相对较重的修改开销。
4. 但是，凡事都是有代价的，Concurrent往往提供了较低的遍历一致性。你可以这样理解所谓的弱一致性，例如，当利用迭代器遍历时，如果容器发生修改，迭代器仍然可以继续进行遍历
5. 与弱一致性对应的，就是同步容器常见的行为“fast-fail”，也就是检测到容器在遍历过程中发生了修改，则抛出ConcurrentModifcationException，不再继续遍历。
6. 弱一致性的另外一个体现是，size等操作准确性是有限的，未必是100%准确
7. 与此同时，读取的性能具有一定的不确定性

10. Java并发类库提供的线程池有哪几种？ 分别有什么特点？

1. Executors目前提供了5种不同的线程池创建配置
   1. newCachedThreadPool()，它是一种用来处理大量短时间工作任务的线程池，具有几个鲜明特点：它会试图缓存线程并重用，当无缓存线程可用时，就会创建新的工作线程；如果线程闲置的时间超过60秒，则被终止并移出缓存；长时间闲置时，这种线程池，不会消耗什么资源。其内部使用SynchronousQueue作为工作队列
   2. newFixedThreadPool(int nThreads)，重用指定数目（nThreads）的线程，其背后使用的是无界的工作队列，任何时候最多有nThreads个工作线程是活动的。这意味着，如果任务数量超过了活动队列数目，将在工作队列中等待空闲线程出现；如果有工作线程退出，将会有新的工作线程被创建，以补足指定的数目nThreads。
   3. newSingleThreadExecutor()，它的特点在于工作线程数目被限制为1，操作一个无界的工作队列，所以它保证了所有任务的都是被顺序执行，最多会有一个任务处于活动状态，并且不允许使用者改动线程池实例，因此可以避免其改变线程数目
   4. newSingleThreadScheduledExecutor()和newScheduledThreadPool(int corePoolSize)，创建的是个ScheduledExecutorService，可以进行定时或周期性的工作调度，区别在于单一工作线程还是多个工作线程。
   5. newWorkStealingPool(int parallelism)，这是一个经常被人忽略的线程池，Java 8才加入这个创建方法，其内部会构建ForkJoinPool，利用Work-Stealing算法，并行地处理任务，不保证处理顺序。
   6. 线程数大致计算 线程数 = CPU核数 × （1 + 平均等待时间/平均工作时间）

11. 谈谈JVM内存区域的划分，哪些区域可能发生OutOfMemoryError？

1. 程序计数器（PC，Program Counter Register）。在JVM规范中，每个线程都有它自己的程序计数器，并且任何时间一个线程都只有一个方法在执行，也就是所谓的当前方法。程序计数器会存储当前线程正在执行的Java方法的JVM指令地址；或者，如果是在执行本地方法，则是未指定值（undefned）。
2. Java虚拟机栈（Java Virtual Machine Stack），早期也叫Java栈。每个线程在创建时都会创建一个虚拟机栈，其内部保存一个个的栈帧（Stack Frame），对应着一次次的Java方法调用。
   前面谈程序计数器时，提到了当前方法；同理，在一个时间点，对应的只会有一个活动的栈帧，通常叫作当前帧，方法所在的类叫作当前类。如果在该方法中调用了其他方法，对应的新的栈帧会被创建出来，成为新的当前帧，一直到它返回结果或者执行结束。JVM直接对Java栈的操作只有两个，就是对栈帧的压栈和出栈。
   栈帧中存储着局部变量表、操作数（operand）栈、动态链接、方法正常退出或者异常退出的定义等。
3. 堆（Heap），它是Java内存管理的核心区域，用来放置Java对象实例，几乎所有创建的Java对象实例都是被直接分配在堆上。堆被所有的线程共享，在虚拟机启动时，我们指定的“Xmx”之类参数就是用来指定最大堆空间等指标。
   理所当然，堆也是垃圾收集器重点照顾的区域，所以堆内空间还会被不同的垃圾收集器进行进一步的细分，最有名的就是新生代、老年代的划分。
4. 方法区（Method Area）。这也是所有线程共享的一块内存区域，用于存储所谓的元（Meta）数据，例如类结构信息，以及对应的运行时常量池、字段、方法代码等。
   由于早期的Hotspot JVM实现，很多人习惯于将方法区称为永久代（Permanent Generation）。Oracle JDK 8中将永久代移除，同时增加了元数据区（Metaspace）
5. 本地方法栈（Native Method Stack）。它和Java虚拟机栈是非常相似的，支持对本地方法的调用，也是每个线程都会创建一个。在Oracle Hotspot JVM中，本地方法栈和Java虚拟机栈是在同一块儿区域，这完全取决于技术实现的决定，并未在规范中强制
   
6. 两点区别
   • 直接内存（Direct Memory）区域，它就是Direct Bufer所直接分配的内存，也是个容易出现问题的地方。尽管，在JVM工程师的眼中，并不认为它是JVM内部内存的一部分，也并未体现JVM内存模型中。
   • JVM本身是个本地程序，还需要其他的内存去完成各种基本任务，比如，JIT Compiler在运行时对热点方法进行编译，就会将编译后的方法储存在Code Cache里面；GC等功能需要运行在本地线程之中，类似部分都需要占用内存空间。这些是实现JVM JIT等功能的需要，但规范中并不涉及
7. 除了程序计数器，其他区域都有可能会因为可能的空间不足发生OutOfMemoryError，简单总结如下：
   • 堆内存不足是最常见的OOM原因之一，抛出的错误信息是“java.lang.OutOfMemoryError:Java heap space”，原因可能千奇百怪，例如，可能存在内存泄漏问题；也很有可能就是堆的大小不合理，比如我们要处理比较可观的数据量，但是没有显式指定JVM堆大小或者指定数值偏小；或者出现JVM处理引用不及时，导致堆积起来，内存无法释放等。
   • 而对于Java虚拟机栈和本地方法栈，这里要稍微复杂一点。如果我们写一段程序不断的进行递归调用，而且没有退出条件，就会导致不断地进行压栈。类似这种情况，JVM实际会抛出StackOverFlowError；当然，如果JVM试图去扩展栈空间的的时候失败，则会抛出OutOfMemoryError。
   • 对于老版本的Oracle JDK，因为永久代的大小是有限的，并且JVM对永久代垃圾回收（如，常量池回收、卸载不再需要的类型）非常不积极，所以当我们不断添加新类型的时
     候，永久代出现OutOfMemoryError也非常多见，尤其是在运行时存在大量动态类型生成的场合；类似Intern字符串缓存占用太多空间，也会导致OOM问题。对应的异常信息，会标记出来和永久代相关：“java.lang.OutOfMemoryError: PermGen space”。
   • 随着元数据区的引入，方法区内存已经不再那么窘迫，所以相应的OOM有所改观，出现OOM，异常信息则变成了：“java.lang.OutOfMemoryError: Metaspace”。直接内存不足，也会导致OOM

12. 如何监控和诊断JVM堆内和堆外内存使用？

1. 可以使用综合性的图形化工具，如JConsole、VisualVM（注意，从Oracle JDK 9开始，VisualVM已经不再包含在JDK安装包中）等。这些工具具体使用起来相对比较直观，直接连接到Java进程，然后就可以在图形化界面里掌握内存使用情况
2. 也可以使用命令行工具进行运行时查询，如jstat和jmap等工具都提供了一些选项，可以查看堆、方法区等使用数据。
3. 或者，也可以使用jmap等提供的命令，生成堆转储（Heap Dump）文件，然后利用jhat或Eclipse MAT等堆转储分析工具进行详细分析。
4. 如果你使用的是Tomcat、Weblogic等Java EE服务器，这些服务器同样提供了内存管理相关的功能。
5. 另外，从某种程度上来说，GC日志等输出，同样包含着丰富的信息。

jdk自带实用工具 https://www.jianshu.com/p/36ac6403df44

1. 为什么CMS两次标记时要 stop the world？
   • 两次标记为了安全回收对象，虚拟机在特定的指令位置设置了“安全点”，当运行到该位置时，程序就会停顿，暂停当前运行的所有用户线程，进而进行标记清除
   • 特定指令的位置：
     • 循环末尾
     • 方法返回前/调用方法call指令之后
     • 可能抛异常的地方

13. 谈谈你的GC调优思路？

1. 从性能的角度看，通常关注三个方面，内存占用（footprint）、延时
   （latency）和吞吐量（throughput）
2. 基本的调优思路可以总结为：
   • 确定调优目标，比如服务停顿严重，希望GC暂停尽量控制在200ms以内，并且保证一定标准的吞吐量
   • 通过jstat等工具查看GC等相关状态，可以开启GC日志，或者是利用操作系统提供的诊断工具等
   • 选择的GC类型是否符合我们的应用特征，如CMS和G1都是更侧重于低延迟的GC选项。
   • 根据实际情况调整新生代老年代比例和大小等
3. 思路归纳为：
   1. 选择合适的垃圾收集器；
   2. 使用jdk工具分析GC状况；
   3. 调整gc参数

14. Java内存模型中的happen-before是什么？

1. Happen-before关系，是Java内存模型中保证多线程操作可见性的机制
2. 它的具体表现形式，包括但远不止是我们直觉中的synchronized、volatile、lock操作顺序等方面，例如：
   • 线程内执行的每个操作，都保证happen-before后面的操作，这就保证了基本的程序顺序规则，这是开发者在书写程序时的基本约定。
   • 对于volatile变量，对它的写操作，保证happen-before在随后对该变量的读取操作。
   • 对于一个锁的解锁操作，保证happen-before加锁操作。
   • 对象构建完成，保证happen-before于fnalizer的开始动作。
   • 甚至是类似线程内部操作的完成，保证happen-before其他Thread.join()的线程等。
     

15. Java程序运行在Docker等容器环境有哪些新问题？

1. Docker其内存、CPU等资源限制是通过CGroup（Control Group）实现的，早期的JDK版本（8u131之前）并不能识别这些限制，进而会导致一些基础问题：
   • 如果未配置合适的JVM堆和元数据区、直接内存等参数，Java就有可能试图使用超过容器限制的内存，最终被容器OOM kill，或者自身发生OOM。
   • 错误判断了可获取的CPU资源，例如，Docker限制了CPU的核数，JVM就可能设置不合适的GC并行线程数等
   • 从应用打包、发布等角度出发，JDK自身就比较大，生成的镜像就更为臃肿，当我们的镜像非常多的时候，镜像的存储等开销就比较明显了
2. 虽然看起来Docker之类容器和虚拟机非常相似，例如，它也有自己的shell，能独立安装软件包，运行时与其他容器互不干扰。但是，如果深入分析你会发现，Docker并不是一种完全的虚拟化技术，而更是一种轻量级的隔离技术。
   
3. 容器虽然省略了虚拟操作系统的开销，实现了轻量级的目标，但也带来了额外复杂性，它限制对于应用不是透明的，需要用户理解Docker的新行为。

4. 针对这种情况，JDK 9中引入了一些实验性的参数，以方便Docker和Java“沟通”，例如针对内存限制，可以使用下面的参数设置

   -XX:+UnlockExperimentalVMOptions
   -XX:+UseCGroupMemoryLimitForHeap

5. 如果你可以切换到JDK 10或者更新的版本，问题就更加简单了。Java对容器（Docker）的支持已经比较完善，默认就会自适应各种资源限制和实现差异。前面提到的实验性参
   数“UseCGroupMemoryLimitForHeap”已经被标记为废弃。与此同时，新增了参数用以明确指定CPU核心的数目。

   -XX:ActiveProcessorCount=N

6. 如果实践中发现有问题，也可以使用“-XX:-UseContainerSupport”，关闭Java的容器支持特性
7. 如果只能使用老版本
   • 明确设置堆、元数据区等内存区域大小，保证Java进程的总大小可控
   • 能在环境中，这样限制容器内存：
     • $ docker run -it --rm --name yourcontainer -p 8080:8080 -m 800M repo/your-java-container:openjdk
   • 额外配置下面的环境变量，直接指定JVM堆大小。
     • -e JAVA_OPTIONS='-Xmx300m'
   • 明确配置GC和JIT并行线程数目，以避免二者占用过多计算资源。
     • -XX:ParallelGCThreads -XX:CICompilerCount
   • 建议配置下面参数，明确告知JVM系统内存限额。
     • -XX:MaxRAM=cat /sys/fs/cgroup/memory/memory.limit_in_bytes
   • 也可以指定Docker运行参数，例如：
     • --memory-swappiness=0

16. 你了解Java应用开发中的注入攻击吗？

1. 注入式（Inject）攻击是一类非常常见的攻击方式，其基本特征是程序允许攻击者将不可信的动态内容注入到程序中，并将其执行，这就可能完全改变最初预计的执行过程，产生恶意效果
2. 最常见的SQL注入攻击。一个典型的场景就是Web系统的用户登录功能，根据用户输入的用户名和密码，我们需要去后端数据库核实信息。
3. 假设应用逻辑是，后端程序利用界面输入动态生成类似下面的SQL，然后让JDBC执行。

Select * from use_info where username = "input_usr_name" and password = "input_pwd"

但是，如果我输入的input_pwd是类似下面的文本

" or ""="

那么，拼接出的SQL字符串就变成了下面的条件，OR的存在导致输入什么名字都是复合条件的。

Select * from use_info where username = “input_usr_name” and password = “” or “” = “”

1. 第二，操作系统命令注入。
2. 第三，XML注入攻击。
3. 解决方法，例如针对SQL注入：
   • 在数据输入阶段，填补期望输入和可能输入之间的鸿沟。可以进行输入校验，限定什么类型的输入是合法的，例如，不允许输入标点符号等特殊字符，或者特定结构的输入。
   • 在Java应用进行数据库访问时，如果不用完全动态的SQL，而是利用PreparedStatement，可以有效防范SQL注入。不管是SQL注入，还是OS命令注入，程序利用字符串拼接
     生成运行逻辑都是个可能的风险点！
   • 在数据库层面，如果对查询、修改等权限进行了合理限制，就可以在一定程度上避免被注入删除等高破坏性的代码。

17. 后台服务出现明显“变慢”，谈谈你的诊断思路？

1. 理清问题的症状，这更便于定位具体的原因，有以下一些思路：
   • 问题可能来自于Java服务自身，也可能仅仅是受系统里其他服务的影响。初始判断可以先确认是否出现了意外的程序错误，例如检查应用本身的错误日志。
   • 监控Java服务自身，例如GC日志里面是否观察到Full GC等恶劣情况出现，或者是否Minor GC在变长等；利用jstat等工具，获取内存使用的统计信息也是个常用手段；利用jstack等工具检查是否出现死锁等
   • 如果还不能确定具体问题，对应用进行Profling也是个办法，但因为它会对系统产生侵入性，如果不是非常必要，大多数情况下并不建议在生产系统进行。
2. 大致可以分几个方面检查
   1. 系统异常报错
   2. JVM配置不合理或内存不够，FULL gc频繁
   3. 检查变慢接口具体代码，可能由于数据量增多，sql没有优化查询变慢
   4. 调用第三方接口变慢

18. mybatis架构划分

1. mybatis架构自下而上分为基础支撑层、数据处理层、API接口层这三层。
   1. 基础支撑层，主要是用来做连接管理、事务管理、配置加载、缓存管理等最基础组件，为上层提供最基础的支撑。
   2. 数据处理层，主要是用来做参数映射、sql解析、sql执行、结果映射等处理，可以理解为请求到达，完成一次数据库操作的流程。
   3. API接口层，主要对外提供API，提供诸如数据的增删改查、获取配置等接口。

19. 谈谈Spring Bean的生命周期和作用域？

Spring Bean生命周期比较复杂，可以分为创建和销毁两个过程。

1. 首先，创建Bean会经过一系列的步骤，主要包括：
   1. 实例化Bean对象。
   2. 设置Bean属性。
   3. 如果我们通过各种Aware接口声明了依赖关系，则会注入Bean对容器基础设施层面的依赖。具体包括BeanNameAware、BeanFactoryAware和ApplicationContextAware，
   4. 分别会注入Bean ID、Bean Factory或者ApplicationContext。
   5. 调用BeanPostProcessor的前置初始化方法postProcessBeforeInitialization。
   6. 如果实现了InitializingBean接口，则会调用afterPropertiesSet方法。
   7. 调用Bean自身定义的init方法。
   8. 调用BeanPostProcessor的后置初始化方法postProcessAfterInitialization。
      创建过程完毕
      
2. 第二，Spring Bean的销毁过程会依次调用DisposableBean的destroy方法和Bean自身定制的destroy方法.

20. 对比Java标准NIO类库，你知道Netty是如何实现更高性能的吗？

1. 单独从性能角度，Netty在基础的NIO等类库之上进行了很多改进，例如：
   1. 更加优雅的Reactor模式实现、灵活的线程模型、利用EventLoop等创新性的机制，可以非常高效地管理成百上千的Channel。
   2. 充分利用了Java的Zero-Copy机制，并且从多种角度，“斤斤计较”般的降低内存分配和回收的开销。例如，使用池化的Direct Bufer等技术，在提高IO性能的同时，减少了对象的创建和销毁；利用反射等技术直接操纵SelectionKey，使用数组而不是Java容器等。
   3. 使用更多本地代码。例如，直接利用JNI调用Open SSL等方式，获得比Java内建SSL引擎更好的性能。
   4. 在通信协议、序列化等其他角度的优化。
      
2. 对比Java标准NIO的代码，Netty提供的相对高层次的封装，减少了对Selector等细节的操纵，而EventLoop、Pipeline等机制则简化了编程模型，开发者不用担心并发等问题，在一定程度上简化了应用代码的开发。最难能可贵的是，这一切并没有以可靠性、可扩展性为代价，反而将其大幅度提高。

21. 谈谈常用的分布式ID的设计方案？Snowfake是否受冬令时切换影响？

1. 明确通常的分布式ID定义，基本的要求包括：
   1. 全局唯一，区别于单点系统的唯一，全局是要求分布式系统内唯一。
   2. 有序性，通常都需要保证生成的ID是有序递增的。例如，在数据库存储等场景中，有序ID便于确定数据位置，往往更加高效。
2. snowflow实现
   
3. 整体长度通常是64 （1 + 41 + 10+ 12 = 64）位，适合使用Java语言中的long类型来存储
   1. 头部是1位的正负标识位。
   2. 紧跟着的高位部分包含41位时间戳，通常使用System.currentTimeMillis()。
   3. 后面是10位的WorkerID，标准定义是5位数据中心 + 5位机器ID，组成了机器编号，以区分不同的集群节点。
   4. 最后的12位就是单位毫秒内可生成的序列号数目的理论极限
4. 我认为没有影响，你可以从Snowfake的具体算法实现寻找答案。我们知道Snowfake算法的Java实现，大都是依赖于System.currentTimeMillis()，这个数值代表什么呢？从Javadoc可以看出，它是返回当前时间和1970年1月1号UTC时间相差的毫秒数，这个数值与夏/冬令时并没有关系，所以并不受其影响

杨晓峰-java核心技术36讲 链接：https://pan.baidu.com/s/1xX8NEfBg7I5Pk9cXewwmZQ
提取码：ajrn