itScholar001的博客

这个漏洞就是说明网站的HTTP响应头中没有设置Strict-Transport-Security，没有设置则可以通过将https自己手动改成htttp的方式进行访问。HTTP 响应头 Strict-Transport-Security 缺失漏洞。如果此时你用http去访问的话则会报403 forbidden错误。http去访问的话则会报403 forbidden错误。添加了这个之后请求的响应头就会有这一段。2.手动在代码中设置。

博主解决这个问题 发现这个acw_tc是阿里云添加的 不是应用自己本身添加的cookie，所以需要在阿里云开启secure。原因在于cookie没有设置secure属性，导致cookie可以被窃取。安全扫描的时候出现这个漏洞-Cookie Secure 缺失漏洞。也可以通过header设置 通过在响应头设置set-Cookie。如果有其他cookie需要设置secure 可以参考这个。添加过滤器，将所有的cookie都设置为secure。有这个漏洞 你的cookie则可以被人截取 不安全。

有时候改了pom中的依赖的版本，但是无法判断这个依赖是否真的修改成功了。2.看jar包中的最终依赖文件。这里即可看到最终的依赖版本。这里即可看到最终的依赖版本。1.看idea中的依赖树。在文件夹中打开cmd窗口。

ENGINE=InnoDB AUTO_INCREMENT=1871762861052760066 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT=‘定时任务日志表’;varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci DEFAULT NULL COMMENT ‘当前查询时间段 处理数据中的最大任务处理的最大id’,

切换到a分支，然后在git上选择show diff with workins tree。4.将b分支合并到a分支时，将多次的commit记录合并成一个新的提交记录。则刚刚commit的内容修改会被取消，且可以再次commit。3.比较当前版本和历史某个版本的代码差异。5.普通merge和压缩merge的区别。5.普通merge和压缩merge的区别。2.取消commit的文件。选择undo commit。commit 测试11。1.对比两个分支差异。

新建test类ApplicationTests。1.新建springboot项目。新建实体类TestData。

新建test类ApplicationTests。1.新建springboot项目。新建实体类TestData。

注意有zip和exe两种格式的，zip（64-bit Windows zip(pgp,md5,sha1)）是免安装版的，exe（32-bit/64-bit Windows Service installer(pgp,md5,sha1)）是安装版。1、进入官网http://tomcat.apache.org/，选择download，下载所需Tomcat版本。2、找到目录bin下的startup.bat，点击启动Tomcat；此处我们选择下载最新版本Tomcat 9。一、下载Tomcat。

此时cmd中输入jvisualvm，如果path配置好了，则会弹出窗口。利用java visualvm 分析内存溢出oom。5.生成dump文件后从dump堆中分析oom原因。此时visualvm中就可以看到这个项目了。线上一般会导出来一个堆的hprof文件。1.准备一段oom的测试java代码。然后就和上面的分析方法一样了。2.启动visualvm。

2.安装成功后，重启idea，此时启动按钮旁边有这两个按钮。idea 安装visualVM插件用于分析java程序，1.在插件市场安装visualvm launcher。3.需要在这里配置插件的visualvm位置。4.配置完后，点击启动。

需要在pom文件添加这个。然后reload项目。

前端界面展示支付二维码，客户扫码支付，支付成功后，钱到支付宝账户；支付宝发起回调通知，调用商城系统回调接口，回调接口将支付流水（用户转给品牌商的流水）状态修改为支付成功；然后将收款单状态流转为已收款，将订单流转为待出库；同时发起两次转账请求，一个是品牌商转账给经销商，一个是品牌商转账给中间商的手续费；通过返回的应收账款信息，前端组装数据，调用生成收款单接口，此接口调用支付宝支付1011请求，生成支付流水（此时支付流水为用户转给品牌商），1011请求此时默认返回待支付状态，与支付二维码返回给前端。

springboot 程序运行一段时间后收不到redis订阅的消息。

缓冲区的功能是用一块内存空间来暂时存放命令数据，以免出现因为数据和命令的处理速度慢于发送速度而导致的数据丢失和性能问题。但因为缓冲区的内存空间有限，如果往里面写入数据的速度持续地大于从里面读取数据的速度，会导致缓冲区需要越来越多的内存来暂存数据。缓冲区占用的内存超出了设定的上限阈值时，会出现缓冲区溢出。如果发生了溢出，会丢数据了。随着累积的数据越来越多，缓冲区占用内存空间越来越大，一旦耗尽了 Redis 实 例所在机器的可用内存，就会导致 Redis 实例崩溃。

比喻（假设）：就像每个人（用户）在每个国家（小程序）有不同的身份证（OpenID），在中国有在中国的身份证，在美国有在美国的身份证；每一个人有一个全球身份证（UnionID），即在不同的小程序用户的UnionID不变。AppID:小程序的身份证号码，是微信公众平台上的小程序 ID，有了它，微信客户端才能确定你的小程序“身份”，并使用微信提供的高级接口。同一个用户在不同的小程序中的 OpenID 是不一样的。UnionID:同一用户，对同一个微信开放平台下的不同应用，UnionID 是相同的。

当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象后，将这个虚引用加入引用队列，以通知应用程序对象的回收情况。相对的，软引用、弱引用和虚引用的对象是软可触及、弱可触及和虚可触及的，在一定条件下，都是可以被回收的。弱引用和软引用一样，在构造弱引用时，也可以指定一个引用队列，当弱引用对象被回收时，就会加入指定的引用队列，通过这个队列可以跟踪对象的回收情况。在 Java 程序中，最常见的引用类型是强引用（普通系统 99%以上都是强引用），也就是我们最常见的普通对象引用，也是默认的引用类型。

增加了redis分布式锁，但是还是生成了重复数据。

并发修改账户余额不一致问题与解决方法悲观锁select…for update。

朋友们在遇到线程安全问题的时候，大多数情况下可能会使用synchronized关键字，每次只允许一个线程进入锁定的方法或代码块，这样就可以保证操作的原子性，保证对公共资源的修改不会出现莫名其妙的问题。这种加锁的机制，在并发量小的情况下还好，如果并发量较大时，会有大量的线程等待同一个对象锁，会造成系统吞吐量直线下降。JDK的开发者可能也考虑到使用synchronized的弊端，于是出现了volatile 和 ThreadLocal等另外的思路解决线程安全问题。

哪些东西可以放入gcroot。

3. 替代redis的事务功能：redis自带的事务功能很鸡肋，而redis的lua脚本几乎实现了常规的事务功能，官方推荐如果要使用redis的事务功能可以用redis lua替代。2. 原子操作：Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。管道不是原子的，不过redis的批量操作命令(类似mset)是原子的。1. 减少网络开销：本来5次网络请求的操作，可以用一个请求完成，原先5次请求的逻辑放在redis服务器上完成。arg [arg …key [key …numkeys 是键的数量。

看门狗。

看门狗机制是Redission提供的一种自动延期机制，这个机制使得Redission提供的分布式锁是可以自动续期的。看门狗机制提供的默认超时时间是30*1000毫秒，也就是30秒如果一个线程获取锁后，运行程序到释放锁所花费的时间大于锁自动释放时间（也就是看门狗机制提供的超时时间30s），那么Redission会自动给redis中的目标锁延长超时时间。在Redission中想要启动看门狗机制，那么我们就不用获取锁的时候自己定义leaseTime(锁自动释放时间)。如果自己定义了锁自动释放时间的话，无论是通过。

过滤器实现的是 javax.servlet.Filter 接口，而这个接口是在Servlet规范中定义的，也就是说过滤器Filter 的使用要依赖于Tomcat等容器，导致它只能在web程序中使用。拦截器 Interceptor 是在请求进入servlet后，在进入Controller之前进行预处理的，Controller 中渲染了对应的视图之后请求结束。过滤器和拦截器 底层实现方式不相同，过滤器是基于函数回调的，拦截器则是基于Java的反射机制（动态代理）实现的。过滤器 和 拦截器的触发时机不同。

在阎宏博士的《JAVA与模式》一书中开头是这样描述状态（State）模式的：**　　状态模式，又称状态对象模式（Pattern of Objects for States），状态模式是对象的行为模式。****　　状态模式允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。**

1.前端调用发送短信接口前，通过密钥（1234abcd）与加密算法，将miyao1234+（16位英文字母与数字字符串） 例如miyao1234wgly1noKSXg47Mn6 进行加密。5.如果解密后包含约定字符串miyao1234，则通过校验，此时注意⚠️，需要将此校验码存入redis，下次如果有相同校验码 则提示重复。前端增加图形验证码，点击发送按钮后增加60s倒计时，60s后才可以再次点击。3.后端接收到后对校验码进行解密，如果解密失败，提示失败。2.前端调用发送短信接口时，将校验码传递给后端。

记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些JVM内存分配机制以及常用的JVM问题排查指令和工具分享，希望对大家有所帮助。在整个排查过程中，我也走了不少弯路，但是在文章中我仍然会把完整的思路和想法写出来，当做一次经验教训，给后人参考，文章最后也总结了下内存泄漏问题快速排查的几个原则。故障描述和排查过程故障原因和解决方案分析JVM堆内内存和堆外内存分配原理常用的进程内存泄漏排查指令和工具介绍和使用文章撰写不易，请大家多多支持我的原创技术公众号：后端技术漫谈。

微笑挖坑，努力填坑。———— 已经拥有黑眼圈，但还没学会小猪老师时间管理学的蛮三刀同学本文是秒杀系统的第四篇，我们来讨论秒杀系统中缓存热点数据的问题，进一步延伸到数据库和缓存的双写一致性问题，并且给出了实现代码。零基础上手秒杀系统（一）：防止超卖。

时光飞逝，两周过去了，是时候继续填坑了，不然又要被网友喷了。本文是秒杀系统的第三篇，通过实际代码讲解，帮助你了解秒杀系统设计的关键点，上手实际项目。抢购接口隐藏单用户限制频率（单位时间内限制访问次数）当然，这两个措施放在任何系统中都有用，严格来说并不是秒杀系统独特的设计，所以今天的内容也会比较的通用。零基础上手秒杀系统（一）：防止超卖本项目的代码开源在了Github，大家随意使用：希望大家多多支持我的公主号：后端技术漫谈。

本文是秒杀系统的第二篇，通过实际代码讲解，帮助你快速的了解秒杀系统的关键点，上手实际项目。本篇主要讲解接口限流措施，接口限流其实定义也非常广，接口限流本身也是系统安全防护的一种措施令牌桶限流单用户访问频率限流抢购接口隐藏此外，前文发出后很多同学对于乐观锁在高并发时无法卖出全部商品提出了“严正抗议”，所以还是在本篇中补充讲解下乐观锁与悲观锁。从零开始打造简易秒杀系统：防止超卖从零开始打造简易秒杀系统：接口限流（令牌桶限流）+ 再谈超卖。

大家好，好久不发文章了。（快一个月了- -）最近有很多学习的新知识想和大家分享，但无奈最近项目蛮忙的，很多文章写了一半搁置在了笔记里，待以后慢慢补充发布。本文主要是通过实际代码讲解，帮助你一步步搭建一个简易的秒杀系统。从而快速的了解秒杀系统的主要难点，并且迅速上手实际项目。从零开始打造简易秒杀系统：乐观锁防止超卖从零开始打造简易秒杀系统：令牌桶限流从零开始打造简易秒杀系统：Redis 缓存从零开始打造简易秒杀系统：消息队列异步处理订单欢迎关注我的公众号：后端技术漫谈（二维码见底部）

最近在做代码重构，发现了很多代码的烂味道。其他的不多说，今天主要说说那些又臭又长的if…else要如何重构。在介绍更更优雅的编程之前，让我们一起回顾一下，不好的if…else代码。

对于从事java开发工作的同学来说，spring的事务肯定再熟悉不过了。在某些业务场景下，如果一个请求中，需要同时写入多张表的数据。为了保证操作的原子性（要么同时成功，要么同时失败），避免数据不一致的情况，我们一般都会用到spring事务。，就能轻松搞定事务。我猜大部分小伙伴也是这样用的，而且一直用一直爽。但如果你使用不当，它也会坑你于无形。今天我们就一起聊聊，事务失效的一些场景，说不定你已经中招了。不信，让我们一起看看。

在庞大的java体系中，spring有着举足轻重的地位，它给每位开发者带来了极大的便利和惊喜。我们都知道spring是创建和管理bean的工厂，它提供了多种定义bean的方式，能够满足我们日常工作中的多种业务场景。那么问题来了，你知道spring中有哪些方式可以定义bean？我估计很多人会说出以下三种：没错，但我想说的是以上三种方式只是开胃小菜，实际上spring的功能远比你想象中更强大。各位看官如果不信，请继续往下看。

建议在项目中少使用@Transactional注解开启事务。但并不是说一定不能用它，如果项目中有些业务逻辑比较简单，而且不经常变动，使用@Transactional注解开启事务开启事务也无妨，因为它更简单，开发效率更高，但是千万要小心事务失效的问题。在spring中为了支持编程式事务，专门提供了一个类：TransactionTemplate，在它的execute方法中，就实现了事务的功能。注解声明式事务，我更建议大家使用，基于。

记录一次线上JVM堆外内存泄漏问题的排查过程与思路，其中夹带一些JVM内存分配机制以及常用的JVM问题排查指令和工具分享，希望对大家有所帮助。在整个排查过程中，我也走了不少弯路，但是在文章中我仍然会把完整的思路和想法写出来，当做一次经验教训，给后人参考，文章最后也总结了下内存泄漏问题快速排查的几个原则。故障描述和排查过程故障原因和解决方案分析JVM堆内内存和堆外内存分配原理常用的进程内存泄漏排查指令和工具介绍和使用文章撰写不易，请大家多多支持我的原创技术公众号：后端技术漫谈。

循环依赖：说白是一个或多个对象实例之间存在直接或间接的依赖关系，这种依赖关系构成了构成一个环形调用。第一种情况：自己依赖自己的直接依赖第二种情况：两个对象之间的直接依赖第三种情况：多个对象之间的间接依赖图片前面两种情况的直接循环依赖比较直观，非常好识别，但是第三种间接循环依赖的情况有时候因为业务代码调用层级很深，不容易识别出来。

说实话，个人认为springboot自带的Conditional系列已经可以满足我们绝大多数的需求了。但如果你有比较特殊的场景，也可以自定义自定义Conditional。@OverrideSystem.out.println("实现自定义逻辑");第三步，使用@MyConditionOnProperty注解。

singleton 单例，每次从spring容器中获取到的bean都是同一个对象。prototype 多例，每次从spring容器中获取到的bean都是不同的对象。RequestScope 同一次请求从spring容器中获取到的bean都是同一个对象。SessionScope 同一个会话从spring容器中获取到的bean都是同一个对象。即便如此，有些场景还是无法满足我们的要求。比如，我们想在同一个线程中从spring容器获取到的bean都是同一个对象，该怎么办？

前几篇文章本打算写spring aop的，但是强忍着没有写（旁白：也有可能是没想好该怎么写😝），就是为了今天整个专题，因为它是spring中最核心的技术之一，实在太重要了。关于spring aop的文章网上一搜一大堆，但我想写点不一样的东西，尝试一种全新的写作风格，希望您会喜欢。