本文主要是介绍java学习——实际情景问题（持续更新），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
上一篇传送门：点我
学到了就是自己的东西，早晚可以派上用场！
MySQL有哪些性能优化方式
MySQL的性能优化可以分为以下四个方面：
1.硬件和操作系统层面的优化：从硬件层面来说，影响MySQL性能的主要因素是CPU、可用内存大小、磁盘读写速度、网络带宽；从操作系统层面来说，应用文件句柄数、操作系统的网络配置都会影响到MySQL的性能，这部分的优化通常是由DBA或者运维工程师去完成，在硬件基础资源的优化中，我们应该重点去关注的是服务本身所承载的体量，然后提出合理的指标要求，避免出现资源浪费的现象。
2.架构设计层面的优化：MySQL是一个磁盘IO访问非常频繁的关系型数据库，在高并发和高性能的场景中，MySQL数据库必然会承受巨大的并发压力，此时我们的优化方式主要可以分为以下几个部分：第一个是搭建MySQL主从集群，单个MySQL服务容易出现单点故障，一旦服务宕机，将会导致依赖MySQL数据库的应用全部无法响应，主从集群可以保证服务的高可用性；第二个是采用读写分离的设计，在读多写少的场景中，通过读写分离的方案，可以避免读写冲突的发生所导致的性能问题；第三个是引入分库分表的机制，通过分库，可以降低单个服务器接受的IO压力，通过分表的方式，可以降低单表的数据量，从而提升SQL查询的效率；第四个是针对热点数据，可以引入更为高效的缓存数据库，比如Redis，从而很好地缓解MySQL数据库的访问压力，同时提升数据的检索性能。
3.MySQL程序配置的优化：对于MySQL数据库本身的优化，一般可以通过修改MySQL配置文件my.conf来完成，比如修改最大连接数、开启bin log日志、修改缓存池大小配置等，通过根据实际情况修改原本的默认配置，可以达到提升数据库的性能的目的。关于配置项的修改，需要关注两个层面：第一个是配置的作用域，它可以分成会话级别和全局范围；第二个是是否支持热加载。因此针对这两个点，需要注意的是，全局参数的设定对于已经存在的会话是无法生效的，会话参数的设定会随着会话的销毁而失效。
4.SQL执行的优化：SQL执行的优化可以分为三个步骤：
首先是慢SQL的定位和排查，我们可以通过慢查询日志（Slow Query Log）和慢查询日志工具分析，得到有问题的SQL列表；
然后是执行计划分析，针对慢SQL，可以使用关键字explain来去查看当前SQL的执行计划，可以重点关注type、key、rows等字段，从而去定位该SQL执行慢的根本原因，再针对原因进行优化，例如尽量避免用select *，减少不必要的join连接操作；
最后再使用show profile工具，它是MySQL提供的可以用来分析当前会话中SQL语句资源消耗情况的工具，可以用于SQL调优的测量。在当前会话中，默认情况下show profile是关闭状态，打开之后会保存最近15次的运行结果，针对运行慢的SQL，通过profile工具进行详细分析，可以得到SQL执行过程中所有资源的开销情况，如IO开销、CPU开销、内存开销等等。
Redis中的大Key该如何处理？
Redis中的大Key是某个Key对应的value数据量很大，这时候内存的压力会特别大，并且对于大Key的读写操作可能会增加网络传输的延迟，对于大Key的持久化备份也会需要更多的磁盘空间和时间。针对大Key，有以下几种思路：
1.把大Key分割成多个小Key来进行存储，比如把一个大的Hash结构分割成多个小的Hash结构，每一个小的Hash结构代表一部分数据，这样可以减少单个Key的大小，去降低内存的压力；
2.搭建Redis Cluster集群，将Key分配到不同的Hash Slot槽所在的分片上，这样可以降低单个Redis节点的存储压力；
3.如果已经存在了大Key，可以做数据的拆分和迁移，按照业务需求和规则，将大Key拆分成多个小Key，并分布到不同的Redis实例上，然后在迁移完成后，清理掉不需要用的大Key；
4.最后还可以考虑使用压缩算法对大Key的value值进行压缩，从而减少存储空间的占用，也就是说，在存储数据之前对数据进行压缩，在读取的时候进行解压缩，从而节省存储空间。
1亿个数据如何取出最大的前100个
从大规模的数据中取出最大的前100个，可以使用堆数据结构来实现，以下是最小堆的解决办法：
1.创建一个最小堆，并将前100个数据插入到堆中；
2.遍历剩余的数据，对于每个数据，如果比堆顶元素更大，就将堆顶元素弹出，然后再将当前元素插入堆中；
3.继续遍历所有数据，不断维护堆内数据，以确保堆中保留的是最大的100个数据；
4.当遍历完成后，堆中最终的100个元素就是前100个最大的数据。
在Java中，可以用PriorityQueue（优先队列）来实现最小堆。通过调用其中的peek()（查看堆顶元素）、poll()（移除堆顶元素）、offer()（插入堆顶元素），可以保证堆内最终元素为前100个最大元素。
慢SQL问题如何排查？
针对慢SQL问题，首先可以通过慢查询日志（Slow Query Log）分析，从而得到有问题的SQL列表。
然后，可以使用关键字explain来去查看当前慢SQL的执行计划，可以重点关注type、key、rows等字段，与此同时还可以使用show profile（这个命令是默认关闭的）去查看当前sql的各阶段执行时间，从而去定位该SQL执行慢的根本原因。再针对原因进行优化，例如尽量避免用select *，减少不必要的join连接操作，给查询增加索引等等。
性能瓶颈也可能是因为数据库服务器性能不够的原因所导致，不足的CPU、内存或磁盘IO也会导致慢SQL问题的出现，所以还需要确保数据库服务器有足够的资源来处理查询。
同时，如果没有用缓存的话，也可以考虑使用缓存查询，将经常执行的查询结果缓存起来，从而减轻数据库的负担。
有一张200W数据量的会员表，每个会员有长短不一的到期时间，现在希望在快到期之前发送邮件通知续费，该如何实现？
方案一：系统不主动轮询，而是等到用户登录到系统之后，触发一次检查，如果发现用户的过期时间小于设定的阈值，就会触发一次弹窗提醒或是邮件提醒。这种方式规避了轮询的问题，不会对数据库和后端应用造成任何的压力。
但是以上方案的缺点也很明显：如果用户一直不登录，就会一直无法实现会员过期，并且也无法提前去根据自定义策略发送邮件或是续期的提醒信息。
方案二：使用ElasticSearch搜索引擎，把会员表里面的会员id和会员到期时间存储一份到搜索引擎中，搜索引擎由于使用倒排索引，所以非常适合大数据量的快速检索，并且具有高可扩展性和高可靠性，非常适合大规模数据的处理。
方案三：直接使用Redis来实现，用户开通会员后，在Redis里面存储该会员ID，并设置这个ID的过期时间，然后可以使用Redis里面的过期提醒功能，通过修改"notify-keyspace-events “EX” "，并在程序中自定义事件过期处理逻辑，从而实现会员的到期提醒。
方案四：可以使用MQ中的延迟队列，当用户开通会员后，直接计算这个会员的过期时间，然后发送延迟消息到MQ里面，一旦消息达到了过期时间，消费者就可以消费这个消息，从而触发过期提醒。
对接第三方接口时需要注意什么？
1.安全性问题：由于和第三方接口对接的时候会涉及到数据的跨网络传输，为了防止数据被拦截或篡改，需要采用安全的通信机制，如HTTPS协议，以及通过数据签名来避免数据篡改的问题。
2.接口的稳定性和可靠性：接口的稳定性和可靠性是直接影响了用户的体验和业务的正常流程的，所以需要做相对充分的评估和测试。
3.接口是否存在访问限制或者费用：如果接口存在并发量的限制，则需要评估是否满足当前业务的需求；如果存在费用，则需要评估是否满足我们的预算范围。
表数据量很大的时候，影响查询效率的主要因素有哪些？
1.磁盘IO： 数据量大意味着需要从磁盘中读取更多的数据，而磁盘IO速度是相对较慢的，因此会影响查询效率；
2.索引是否生效： 索引是提高查询效率的重要手段，但是如果因为查询条件用了不支持索引的操作符等原因导致索引失效，就会导致查询的效率下降；
3.数据分页： 当需要查询大量数据的时候，数据库需要进行数据分页，而数据分页的过程会占用大量的CPU资源；
4.锁竞争： 当多个事务同时对同一个表进行读写操作时，就会导致锁竞争，而锁竞争会导致查询效率的下降；
4.内存使用： 当表数据量大的时候，需要占用更多的内存空间来缓存数据，如果内存不足，就会导致数据库频繁进行磁盘IO。
数据量多少需要开始考虑分库分表
1.单表的数据量：如果单个表的数据量已经非常大，例如超过了百万级别，就需要开始考虑分表；
2.数据库的性能：当单个数据库的性能无法满足业务需求时，就需要考虑分库；
3.数据库的访问频率：如果某些表的数据访问频率非常高，单个数据库节点可能会无法满足高并发需求，就需要考虑将这些表分到不同的数据库节点上（水平分表），从而提高整个数据库的IO性能；
4.业务拆分：当系统的业务逻辑越来越复杂，不同业务之间的数据耦合度越来越低时，就需要考虑对业务相关数据表进行拆分（垂直分表），从而方便管理和拓展。
JVM调优参数主要有哪些？
对于JVM调优，主要就是调整年轻代、老年代、元空间的内存空间大小以及使用的垃圾回收器类型。常见的JVM调优参数主要有以下几个：
1.设置堆空间的大小：
-Xms：设置堆的初始化大小
-Xmx：设置堆的最大大小不指定单位就会默认单位为字节
最大大小的默认值是物理内存的1/4,初始大小是物理内存的1/64
堆太小，可能会频繁导致年轻代和老年代的垃圾回收，会产生stw，暂停用户线程
堆内存大肯定相对较好，但是如果发生了full gc，就需要扫描整个堆空间，从而导致长时间用户线程的暂停
设置参考推荐：尽量设置大一些，但是也需要考察当前计算机其他程序内存的使用情况
2.虚拟机栈参数的设置： 每个线程默认会开启1M的线程，用于存放栈帧、调用参数、局部变量等，但实际情况下一般256K就够用了。通常情况下，减少每个线程的堆栈，可以产生更多的线程，但这实际上还受限于操作系统。
-Xss 对每个线程stack大小的调整，-Xss128k
3.年轻代中Eden区和两个Survivor区（from区和to区）的大小比例： 设置年轻代中Eden区和两个Survivor区的大小比例，如果该值没有设置，默认比例为8：1：1。通过增大Eden区的大小，来减少Young GC发生的次数，但有时候虽然Young GC次数减少了，但Eden区满的时候，由于占用的空间较大，会导致空间释放缓慢，此时的STW时间较长，因此需要按照程序情况进行调优。
-XXSurvivorRatio=8 表示年轻代中的分配比率：survivor：eden=2：8
4.年轻代晋升老年代阈值：
-XX:MaxTenuringThreshold=threshold默认为15，取值范围为0-15
5.设置垃圾回收器： 通过增大吞吐量提高系统性能，可以提高设置并行垃圾回收收集器。
-XX:+UseParallelGC java8默认的垃圾回收器是Parrallel GC
-XX:+UseG1GC 设置垃圾回收器为G1 GC
JVM调优参数可以在哪里设置？
在IDEA编译器中设置的JVM参数都是临时参数，而在项目部署的时候，JVM的调优参数一般有以下两种设置方式：
1.war包部署在tomcat中设置： 修改TOMCAT_HOME/bin/catalina.sh文件，可以在文件中设置具体的JVM参数，例如JAVA_OPTS=“-Xms512m -Xmx1024m”，这表示堆的初始大小为512M，堆的最大大小为1024M.
2.jar包部署在启动参数中设置： 通常可以在linux系统下直接加参数启动Spring Boot项目，例如：“nohup java -Xms512m -Xmx1024m -jar XXXX.jar --spring.profiles.active=prod &”，其中nohup表示的是系统后台不挂断的运行命令，退出终端不会影响程序的进行，而参数&表示的是让命令在后台执行，退出终端后命令依旧执行。
说说JVM调优的工具有哪些？
jps： 列出当前系统上所有运行的Java进程状态信息。在JVM调优中，jps常被用来快速识别正在运行的Java进程，以便进一步的分析和调优。
jstack： 生成Java虚拟机当前时刻的线程快照，即当前Java虚拟机内每一条线程正在执行的方法堆栈的集合。jstack可以帮助我们快速定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等。当线程出现停顿的时候，通过jstack来查看各个线程的调用堆栈，可以知道没有响应的线程到底在后台做什么事情，或者等待什么资源。
jmap： jmap主要包括生成堆栈dump文件、查看堆内的对象信息、类加载器信息等功能。通过这些功能，开发人员可以深入了解Java堆的详细情况，包括对象的数量、类型、大小以及引用关系等，从而识别内存泄漏或者内存溢出等问题。
jstat： jstat是JVM的统计监测工具，它可以用来显示垃圾回收信息、类加载信息、新生代统计信息等。
jconsole： 针对jvm的可视化监测工具，用于对JVM内存、线程、类的监控，是一个GUI性能监控工具。
Java内存泄漏的排查思路是什么？
内存泄漏是指在程序运行过程中，因为某些原因，导致不需要使用的对象仍然占用JVM内存空间，并且这块内存还无法被回收，最终导致程序占用的内存越来越大，从而出现了OOM的错误或是影响程序的性能。一般情况下，除了OOM以外，内存泄露也会出现一些比较明显的现象，比如频繁的Full GC、内存占用量过大一直无法释放等。
内存泄漏的排查需要根据现象去定位问题，首先需要判断是否是内存泄露，比如当遇到老年代逐步增长、Full GC卡顿、年轻代的内存一直在高位无法释放、频繁Full GC等现象时，基本上都是说明内存出现异常，要了解GC的情况，可以使用jstat命令去查看虚拟机中各个内存的使用情况和GC情况，然后使用jmap生成dump文件，并通过MAT工具对dump进行分析，从而通过分析结果对应到出问题的类，然后就可以针对出问题的地方进行代码优化了。
一般情况下，可能是循环引用、内存对象泄漏没有被销毁、动态分配内存以后未被释放、长期持有对象引用等等原因。
这篇关于java学习——实际情景问题（持续更新）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
