快过年，我的线上发布出现故障

“五哥，你在上线吗？”，旁边有一个声音传来。

“啊，怎么了？”。真是要命，在上线发布时候，我最讨厌别人叫我的名字 。我慌忙站起来，看向身后，原来是 建哥在问我。我慌忙的问，怎么回事。

“DBA 刚才在群里说，Task数据库 cpu 负载增加！有大量慢查询”，建哥来我身边，跟我说。

慢慢的，我身边聚集着越来越多的人

“你在上线Task服务吗？改动什么内容了，看看要不要立即回滚？”旁边传来声音。此时，我的心开始怦怦乱跳，手心发痒，紧张不已。

我检查着线上机器的日志，试图证明报警的原因不是出在我这里。

我对着电脑，微微颤抖地回答大家：“我只是升级了基础架构的Jar包，其他内容没有改动啊。”此时我已分不清是谁在跟我说话，只能对着电脑作答……

这时DBA在群里发送了一条SQL，他说这条SQL导致了大量的慢查询。

我突然记起来了，我转过头问林哥：“林哥，你上线了什么内容？”这次林哥有代码的变更，跟我一起上线。我觉得可能是他那边有问题。

果然，林哥看着代码发呆。他嘟囔道：“我添加了索引啊，怎么会有慢查询呢？”原来慢查询的SQL是林哥刚刚添加的，这一刻我心里的石头放下了，问题并不在我，我轻松了许多。

“那我先回滚吧”，幸好我们刚发布了一半，现在回滚还来得及，我尝试回滚机器。此刻我的紧张情绪稍稍平静下来，手也不再发抖。

既然不是我的问题，我可以以吃瓜的心态，暗中观察事态的发展。我心想：真是吓死我了，幸好不是我的错。

然而我也有一些小抱怨：为什么非要和我一起搭车上线，出了事故，还得把我拖进来。

故障发生前的半小时

2年前除夕前的一周，我正准备着过年前的最后一次线上发布，这时候我刚入职两个月，自然而然会被分配一些简单的小活。这次上线的内容是将基础架构的Jar包升级到新版本。一般情况下，这种配套升级工作不会出问题，只需要按部就班上线就行。

“五哥，你是要上线 Task服务吗？”，工位旁的林哥问我，当时我正做着上线前的准备工作。

“对啊，马上要发布，怎么了？”，我转身回复他。

“我这有一个代码变更，跟你搭车一起上线吧，改动内容不太多。已经测试验证过了”，林哥说着，把代码变更内容发给我，简单和我说了下代码变更的内容。我看着改动内容确实不太多，新增了一个SQL查询，于是便答应下来。我重新打包，准备发布上线。

半小时以后，便出现了文章开头的情景。新增加的SQL 导致大量慢查询，数据库险些被打挂。

为什么加了索引，还会出现慢查询呢？

”加了索引，为什么还有慢查询？“，这是大家共同的疑问。

事后分析故障的原因，通过 mysql explain 命令，查看该SQL 确实没有命中索引，从而导致慢查询。

这个SQL 大概长这个样子！我去掉了业务相关的部分。

select * from order_discount_detail where orderId = 1123;

order_discount_detail 在 orderId 这一列上确实加了索引，不应该出现慢查询，乍一看，没有什么问题。我本能的想到了索引失效的几种场景。难道是类型不匹配，导致索引失效？

果不其然， orderId 在数据库中的类型 是 varchar 类型，而传参是按照 long 类型传的。

复习一下： 类型转换导致索引失效

类型转换导致索引失效，是很容易犯的错误

因为在某些特殊场景下要对接外部订单，存在订单Id为字符串的情况，所以 orderId被设计成 varchar 字符串类型。然而出问题的场景比较明确，订单id 就是long类型，不可能是字符串类型。

所以林哥，他在使用Mybatis 时，直接使用 long 类型的 orderId字段传参，并且没有意识到两者数据类型不对。

因为测试环境数据量比较小，即使没有命中索引，也不会有很严重的慢查询，并且测试环境请求量比较低，该慢查询SQL 执行次数较少，所以对数据库压力不大，测试阶段一直没有发现性能问题。

直到代码发布到线上环境————数据量和访问量都非常高的环境，差点把数据库打挂。

mybatis 能避免 “类型转换导致索引失效” 的问题吗？

mybatis能自动识别数据库和Java类型不一致的情况吗？如果发现java类型和数据库类型不一致，自动把java 类型转换为数据库类型，就能避免索引失效的情况！

答案是不能。我没找到 mybatis 有这个能力。

mybatis 使用 #{} 占位符，会自动根据 参数的 Java 类型填充到 SQL中，同时可以避免SQL注入问题。

例如刚才的SQL 在 mybatis中这样写。

select * from order_discount_detail where orderId = #{orderId};

orderId 是 String 类型，SQL就变为

select * from order_discount_detail where orderId = ‘1123’;

mybatis 完全根据 传参的java类型，构建SQL，所以不要认为 mybatis帮你处理好java和数据库的类型差异问题，你需要自己关注这个问题！

再次提醒，"类型转换导致索引失效"的问题，非常容易踩坑。并且很难在测试环境发现性能问题，等到线上再发现问题就晚了，大家一定要小心！小心！

险些背锅

可能有朋友疑问，为什么发布一半时出现慢查询，单机发布阶段不能发现这个问题吗？

之所以没发现这个问题，是因为 新增SQL在 Kafka消费逻辑中，由于单机发布机器启动时没有争抢到 kafka 分片，所以没有走到新代码逻辑。

此外也没有遵循降级上线的代码规范，如果上线默认是降级状态，上线过程中就不会有问题。放量阶段可以通过降级开关快速止损，避免回滚机器过程缓慢而导致的长时间故障。

不是我的问题，为什么我也背了锅

因为我在发布阶段没有遵循规范，按照规定的流程应该在单机发布完成后进行引流压测。引流压测是指修改机器的Rpc权重，将Rpc请求集中到新发布的单机上，这样就能提前发现线上问题。

然而由于我偷懒，跳过了单机引流压测。由于发布的第一台机器没有抢占到Kafka分片，因此无法执行新代码逻辑。即使进行了单机引流压测，也无法提前发现故障。虽然如此，但我确实没有遵循发布规范，错在我。

如果上线时没有出现故障，这种不规范的上线流程可能不会受到责备。但如果出现问题，那只能怪我倒霉。在复盘过程中，我的领导抓住了这件事，给予了重点批评。作为刚入职的新人，被指责确实让我感到不舒服。

快要过年了，就因为搭车上线，自己也要承担别人犯错的后果，让我很难受。但是自己确实也有错，当时我的心情复杂而沉重。

两年前的事了，说出来让大家吃个瓜，乐呵一下。如果这瓜还行，东东发财的小手点个赞

后端接口设计

如果让你设计一个接口，你会考虑哪些问题？

1.接口参数校验

接口的入参和返回值都需要进行校验。

• 入参是否不能为空，入参的长度限制是多少，入参的格式限制，如邮箱格式限制


• 返回值是否为空，如果为空的时候是否返回默认值，这个默认值需要和前端协商

2.接口扩展性

举个例子，比如用户在进行某些操作之后，后端需要进行消息推送，那么是直接针对这个业务流程来开发一个专门为这个业务流程服务的消息推送功能呢？还是说将消息推送整合为一个通用的接口，其他流程都可以进行调用，并非针对特定业务。

这个场景可能光靠说不是很能理解，大家想想策略工厂设计模式，是不是可以根据不同的策略，来选择不同的实现方式呢？再结合上面的这个例子，是否对扩展性有了进一步的理解呢？

3.接口幂等设计

什么是幂等呢？幂等是指多次调用接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致

举个例子，在购物商场里面你用手机下单，要买某个商品，你需要去支付，然后你点击了支付，但是因为网速问题，始终没有跳转到

支付界面，于是你又连点了几次支付，那在没有做接口幂等的时候，是不是你点击了多少次支付，我们就需要执行多少次支付操作？

所以接口幂等到的是什么？防止用户多次调用同一个接口

• 对于查询和删除类型的接口，不论调用多少次，都是不会产生错误的业务逻辑和数据的，因此无需幂等处理


• 对于新增和修改，例如转账等操作，重复提交就会导致多次转账，这是很严重的，影响业务的接口需要做接口幂等的处理，跟前端约定好一个固定的token接口，先通过用户的id获取全局的token，写入到Redis缓存，请求时带上Token，后端做处理

4.关键接口日志打印

关键的业务代码，是需要打印日志进行监测的，在入参和返回值或者如catch代码块中的位置进行日志打印

• 方便排查和定位线上问题，划清责任


• 生产环境是没有办法进行debug的，必须依靠日志查问题，看看到底是出现了什么异常情况

5.核心接口要进行线程池隔离

分类查询啊，首页数据等接口，都有可能使用到线程池，某些普通接口也可能会使用到线程池，如果不做线程池隔离，万一普通接口出现bug把线程池打满了，会导致你的主业务受到影响

6.第三方接口异常重试

如果有场景出现调用第三方接口，或者分布式远程服务的话，需要考虑的问题

• 异常处理
  
  

  比如你在调用别人提供的接口的时候，如果出现异常了，是要进行重试还是直接就是当做失败



• 请求超时
  
  

  有时候如果对方请求迟迟无响应，难道就一直等着吗？肯定不是这样的，需要设法预估对方接口响应时间，设置一个超时断开的机制，以保护接口，提高接口的可用性，举个例子，你去调用别人对外提供的一个接口，然后你去发http请求，始终响应不回来，此时你又没设置超时机制，最后响应方进程假死，请求一直占着线程不释放，拖垮线程池。



• 重试机制
  
  

  如果调用对外的接口失败了或者超时了，是否需要重新尝试调用呢？还是失败了就直接返回失败的数据？

7.接口是否需要采用异步处理

举个例子，比如你实现一个用户注册的接口。用户注册成功时，发个邮件或者短信去通知用户。这个邮件或者发短信，就更适合异步处理。总不能一个通知类的失败，导致注册失败吧。 那我们如何进行异步操作呢？可以使用消息队列，就是用户注册成功后，生产者产生一个注册成功的消息，消费者拉到注册成功的消息，就发送通知。

8.接口查询优化，串行优化为并行

假设我们要开发一个网站的首页，我们设计了一个首页数据查询的接口，这个接口需要查用户信息，需要查头部信息，需要查新闻信息

等等之类的，最简单的就是一个一个接口串行调用，那要是想要提高性能，那就采取并行调用的方式，同时查询，而不是阻塞

可以使用CompletableFuture(推荐)或者FutureTask(不推荐)

        Map<Long, List<SubjectLabelBO>> map = new HashMap<>();

        List<CompletableFuture<Map<Long, List<SubjectLabelBO>>>> completableFutureList = 

        categoryBOList.stream().map(category ->

                CompletableFuture.supplyAsync(() -> getLabelBOList(category), labelThreadPool)

        ).collect(Collectors.toList());

​

        completableFutureList.forEach(future -> {

            try {

                Map<Long, List<SubjectLabelBO>> resultMap = future.get(); //这里会阻塞

                map.putAll(resultMap);

            } catch (Exception e) {

                e.printStackTrace();

            }

        });

        

        public Map<Long, List<SubjectLabelBO>> getLabelBOList(SubjectCategoryBO category) {...}

9.高频接口注意限流

自定义注解 + AOP

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface RateLimiter {

    int value() default 1;

    int durationInSeconds() default 1;

}

​

@Aspect

@Component

public class RateLimiterAspect {

​

    private final ConcurrentHashMap<String, RateLimiter> rateLimiters = new ConcurrentHashMap<>();

​

    @Pointcut("@annotation(RateLimiter)")

    public void rateLimiterPointcut(RateLimiter rateLimiterAnnotation) {

    }

​

    @Around("rateLimiterPointcut(rateLimiterAnnotation)")

    public Object around(ProceedingJoinPoint joinPoint, RateLimiter rateLimiterAnnotation) throws Throwable {

        int permits = rateLimiterAnnotation.value();

        int durationInSeconds = rateLimiterAnnotation.durationInSeconds();

​

        // 使用方法签名作为 RateLimiter 的 key

        String key = joinPoint.getSignature().toLongString();

        com.google.common.util.concurrent.RateLimiter rateLimiter = rateLimiters.computeIfAbsent(key, k -> com.google.common.util.concurrent.RateLimiter.create((double) permits / durationInSeconds));

​

        // 尝试获取令牌，如果获取到则执行方法，否则抛出异常

        if (rateLimiter.tryAcquire()) {

            return joinPoint.proceed();

        } else {

            throw new RuntimeException("Rate limit exceeded.");

        }

    }

}

​

@RestController

public class ApiController {

​

    @GetMapping("/api/limited")

    @RateLimiter(value = 10, durationInSeconds = 60) //限制为每分钟 10 次请求

    public String limitedEndpoint() {

        return "This API has a rate limit of 10 requests per minute.";

    }

​

    @GetMapping("/api/unlimited")

    public String unlimitedEndpoint() {

        return "This API has no rate limit.";

    }

}

10.保障接口安全

配置黑白名单，用Bloom过滤器实现黑白名单的配置

具体代码不贴出来了，大家可以去看看布隆过滤器的具体使用

11.接口控制锁粒度

在高并发场景下，为了防止超卖等情况，我们会对共享资源进行加锁的操作来保证线程安全的问题，但是如果加锁的粒度过大，是会影响

到接口性能的。那什么是加锁粒度呢？举一个例子，你带了一封情书回家，但是不想被爸妈发现，然后你偷偷回到房间里放到一个可以锁

住的抽屉里面，而不用把房间的门锁给锁上。 无论是使用synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉

及共享资源的，就不必要加锁。

• 锁粒度过大：
  
  

  把方法A和方法B全部进行加锁，但是实际上我只是想要对A加锁，这就是锁粒度过大

void test(){

    synchronized (this) {

       B();

       A();

    }

}

• 缩小锁粒度

void test(){

       B();

    synchronized (this) {

       A();

    }

}

12.避免长事务问题

长事务期间可能伴随cpu、内存升高、严重时会导致服务端整体响应缓慢，导致在线应用无法使用

产生长事务的原因除了sql本身可能存在问题外，和应用层的事务控制逻辑也有很大的关系。

• 如何尽可能的避免长事务问题呢？
  
  

  1.RPC远程调用不要放到事务里面

  
  

  2.一些查询相关的操作如果可用，尽量放到事务外面

  
  

  3.并发场景下，尽量避免使用@Transactional注解来操作事务，使用TransactionTemplate的编排式事务来灵活控制事务的范围

在原先使用@Transactional来管理事务的时候是这样的

@Transactional

public int createUser(User user){

    //保存用户信息

    userDao.save(user);

    passCertDao.updateFlag(user.getPassId());

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

使用TransactionTemplat进行编排式事务

@Resource

private TransactionTemplate transactionTemplate;

​

public int createUser(User user){

    transactionTemplate.execute(transactionStatus -> {

      try {

         userDao.save(user);

         passCertDao.updateFlag(user.getPassId());

      } catch (Exception e) {

         // 异常手动设置回滚

         transactionStatus.setRollbackOnly();

      }

      return true;

    });

    // 该方法为远程RPC接口

    sendEmailRpc(user.getEmail());

    return user.getUserId();

}

Hello，大家好，我是云帆。在我们传统的基于SpringBoot开发的项目中，在配置文件里，或多或少的都会有一些敏感信息，这样就会丢失一定的安全性，所以我们就需要，对敏感信息进行加密。我们可以使用jasypt工具进行加密。

好了废话不多少，直接进入正题：

1. 导入依赖

<dependency>  

    <groupId>com.github.ulisesbocchio</groupId>  

    <artifactId>jasypt-spring-boot-starter</artifactId>  

    <version>3.0.5</version>  

</dependency>

我的Demo里使用的是SpringBoot3.0之后的版本，所以大家如果像我一样都是基于SpringBoot3.0之后的，jasypt一定要使用3.0.5以后的版本。

2. 使用jasypt

我们在配置文件里写几行配置

jasypt:  

  encryptor:  

    password: sdjsdbshdbfuasd  

    property:  

      prefix: ENC(

      suffix: )

password是加密密码，必须配置这一项，值可以随便输入。
prefix和suffix是默认配置，也可以自定义，默认值就是ENC(和)，这个是自动解密使用的。

2.1. 加/解密

jasypt 提供了一个工具类接口，StringEncryptor，这个接口提供了加解密方法。下面是他的源码。

public interface StringEncryptor {  

  

    /**  

    * 加密输入信息  

    *  

    * @param 要加密的信息  

    * @return 加密结果  

    */  

    public String encrypt(String message);  





    /**  

    * 解密加密信息  

    *  

    * @param 加密信息（encryptedMessage） 要解密的加密信息  

    * @return 解密结果  

    */  

    public String decrypt(String encryptedMessage);  

  

}

我们在 test 测试类中，将要进行加密的文本使用encrypt方法进行加密

@SpringBootTest  

@Slf4j  

class JasryptApplicationTests {  

  

    @Autowired  

    private StringEncryptor stringEncryptor;  



    @Test  

    void contextLoads() {  

        String username = stringEncryptor.encrypt("root");  

        String password = stringEncryptor.encrypt("root");  

        log.info("username encrypt is {}", username);  

        log.info("password encrypt is {}", password);  

        log.info("username decrypt is {}", stringEncryptor.decrypt(username));  

        log.info("password decrypt is {}", stringEncryptor.decrypt(password));  

    }  

  

}

上边代码，加密的内容是，MySQL的用户名和密码，同时对它们进行加密和解密，你当然可以对任意配置信息进行加解密操作。看看输出内容：

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username encrypt is 61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot

2023-07-23T18:59:50.621+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password encrypt is a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv

2023-07-23T18:59:50.623+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : username decrypt is root

2023-07-23T18:59:50.630+08:00  INFO 9489 --- [           main] c.e.jasrypt.JasryptApplicationTests      : password decrypt is root

加密默认使用的是PBEWITHHMACSHA512ANDAES_256加密
我们将密文，替换到数据源，配置：

spring:  

datasource:  

driver-class-name: com.mysql.cj.jdbc.Driver  

url: jdbc:mysql://localhost:3306/honey?useUnicode=true&zeroDateTimeBehavior=convertToNull&autoReconnect=true&characterEncoding=utf-8  

username: ENC(61zSoixtNayUruXt5x84kEKO9jGnZObTGCa1+k5Yg9F7qSUiZvp5fG31AMuVqrot)  

password: ENC(a6snCZCkbQFKkQqxN2bS18ags04yZxH+THwIL5RjGocEjG9sLkJvvasPFFVxEBWv)

⚠️注意别忘了加上前缀和后缀，如上边代码。

这个时候就已经完成了，但是官方不建议我们将加密密码放到配置文件中，我们应作为系统属性、命令行参数或环境变量传递，只要其名称是 jasypt.encryptor.password，就能正常工作。

我们可以将项目打为jar包然后使用 java -jar命令

java -jar jasrypt-0.0.1-SNAPSHOT.jar --jasypt.encryptor.password=加密密码

⚠️加密密码必须与之前给属性加密时用的加密密码一致。

3. 结尾

好了，分享到这里就结束了，希望小伙伴们多多点赞，如果有建议，欢迎留言。

此致

hi，这里是小榆。在 5 月 15 日，OpenAI 旗下的大模型 GPT-4o 已经发布，那时网络上已经传开， 但很多小伙伴始终没有看到 GPT-4o 的体验选项。

在周五的时候，我组建的 ChatGPT 交流群的伙伴已经发现了 GPT-4o 这个选项了，是在没有充值升级 Plus 版的情况下，意味着这个模型已经更新给大众免费使用了。

我看到后，立马放下手中正在编写的代码，开启 GPT 登录后果然有一个  GPT-4o 的选项，然后发现它的功能比 3.5 模型更加全面了，它不仅能够全面覆盖听觉、视觉和语音。

我体验了一把语音对话，非常的丝滑没感觉到延迟，仿佛真的和“女朋友”在聊天。意味着它能够感知我们的呼吸节奏，并用更加丰富的语气实时回应，还会在适当的时候打断对话。

那么，就让我们了解 GPT-4o 这个大模型吧，首先 GPT-4 是比 3.5 版本更强的版本，即为 4.0+，后面还有一个‘o’ ，它的全称是‘Omni’，即‘全能’的意思。

它能够接受文本、音频和图像的任意组合输入，并生成回答。响应速度快至 232 毫秒，平均 320 毫秒，与人类对话的速度可以说是很接近平均了。

并且，随着这次版本的发布，GPTo 与 ChatGPT Plus 会员版的所有功能，包括视觉、联网、记忆、执行代码、GPT Store 等，都会免费开放给大家。新语音模式将在几周内优先向 Plus 用户开放。

在直播现场，OpenAI CTO Murati 谦虚道：“这是将 GPT-4 级别的模型开放给大家。”

同时将这一版本的模型提供 API 服务，价格随之减少一半，速度比之提高一倍，单位时间内调用次数是原来的 5 倍了。

OpenAI 的总裁 Brockman 也给大家在线演示，将两个 ChatGPT 相互对话，对话内容比较丰富了，不知不觉还唱起歌来了，整的还挺有意思。

发现还有伙伴和我一样体验到了不错的应用场景，当我使用手机版的 GPT-4o ，我可以实时拍照询问它，给我一些建议，如何挑西瓜榴莲等，询问给出差异分析，借助 AI 的力量进行挑瓜。

你甚至可以拍摄一批西瓜的照片，上传给 GPT-4o。

你：“这瓜保熟吗？”

AI：“（警觉）...你故意找茬是不是。”

AI：“我一AI，还能给你挑生瓜蛋子不成？！”

我们可以看到上图中的西瓜是根据自己拍摄的西瓜图并且标记了序号，询问 GPT 哪个西瓜很甜，GPT 一通分析，虽然目前只能根据形状和成色来识别西瓜，推荐挑选的 6 号西瓜果然很不错，甚至皮也很薄。

聪明的你，脑洞大开已经熟练使用 AI 了，你或许会有很多问题问他。

你：“这盒牛奶含有什么成分？”

AI：“......”

你（掏出手机，打开摄像头扫描）：“这盒牛奶有科技成分吗？卫生是否达标？”

AI：“......”

你（掏出手机，打开摄像头扫码）：“请问这个妹妹面相如何？是否旺夫？”

AI：“......”

显然，上面有一部分是我的遐想，但我觉得已经不远了。

如果 AI 没有被一方人污染，升级完全体的情况下，它真的能够为我们参谋很多，洞悉很多潜在的信息，毕竟你能骗我，但是 AI 不会骗我。

好了，大家可以多去体验新产品吧，的确会很有趣。但是发现很多小伙伴 不仅电脑版本的 GPT 无法体验，更别说手机版本的 GPT 了。

目前来说对一些普通用户体验的确很困难，被迫使用某些企业研发的 AI 产品或套壳产品，还被迫收费。但也不是没有办法，别说我还挺想撰写一篇从 0 到 1 给大家完全科普使用。

okay，分享（暗示）到这里，大家如果有感兴趣，可以后台回复 GPT 加入群聊，将会有更多咨询和体验内容分享。

引言：纯干货分享，汇总了我在工作中八年遇到的各种 Nginx 使用场景，对这篇文章进行了细致的整理和层次分明的讲解，旨在提供简洁而深入的内容。希望这能为你提供帮助和启发！

对于前端开发人员来说，Node.js 是一种熟悉的技术。虽然 Nginx 和 Node.js 在某些理念上有相似之处，比如都支持 HTTP 服务、事件驱动和异步非阻塞操作，但两者并不冲突，各有各自擅长的领域：

• Nginx：擅长处理底层的服务器端资源，如静态资源处理、反向代理和负载均衡。


• Node.js：更擅长处理上层的具体业务逻辑。

而两者的结合可以实现更加高效和强大的应用服务架构，下面我们就来看一下。借助文章目录阅读，效率更高。目前您可能还用不到这篇文章，不过可以先收藏起来。希望将来它能为您提供所需的帮助！

Nginx 是什么？

Nginx 是一个高性能的HTTP和反向代理服务器，由俄罗斯程序员Igor Sysoev于 2004 年使用 C 语言开发。它最初设计是为了应对俄罗斯大型门户网站的高流量挑战。

反向代理是什么？（🔥面试会问）

让我们先从代理说起。Nginx 常被用作反向代理，那么什么是正向代理呢？

• 正向代理：客户端知道要访问的服务器地址，但服务器只知道请求来自某个代理，而不清楚具体的客户端。正向代理隐藏了真实客户端的信息。例如，当无法直接访问国外网站时，我们通过代理服务器访问特定网址。

• 反向代理：多个客户端向反向代理服务器发送请求，Nginx 根据一定的规则将请求转发至不同的服务器。客户端不知道具体请求将被转发至哪台服务器，反向代理隐藏了后端服务器的信息。

Nginx 的核心特性

Nginx包含以下七个核心特性，使它成为处理高并发和大数据量请求的理想选择：

1. 事件驱动：Nginx采用高效的异步事件模型，利用 I/O 多路复用技术。这种模型使 Nginx 能在占用最小内存的同时处理大量并发连接。

2. 高度可扩展：Nginx能够支持数千乃至数万个并发连接，非常适合大型网站和高并发应用。例如：为不同的虚拟主机设置不同的 worker 进程数，以增加并发处理能力：

http {

  worker_processes auto; # 根据系统CPU核心数自动设置worker进程数

}

3. 轻量级：相较于传统的基于进程的Web服务器（如Apache），Nginx的内存占用更低，得益于其事件驱动模型，每个连接只占用极小的内存空间。

4. 热部署：Nginx支持热部署功能，允许在不重启服务器的情况下更新配置和模块。例如：在修改了 Nginx 配置文件后，可以快速热部署 Nginx 配置：

sudo nginx -s reload

5. 负载均衡：Nginx内置负载均衡功能，通过upstream模块实现客户端请求在多个后端服务器间的分配，从而提高服务的整体处理能力。以下是一个简单的upstream配置，它将请求轮询分配到三个后端服务器：

upstream backend {

    server backend1.example.com;

    server backend2.example.com;

    server backend3.example.com;

}



server {

    location / {

        proxy_pass http://backend; # 将请求转发到upstream定义的backend组

    }

}

6. 高性能：Nginx 在多项 Web 性能测试中表现卓越，能快速处理静态文件、索引文件及代理请求。比如：配置 Nginx 作为反向代理服务器，为大型静态文件下载服务：

location /files/ {

  alias /path/to/files/; # 设置实际文件存储路径

  expires 30d; # 设置文件过期时间为30天

}

7. 安全性：Nginx支持SSL/TLS协议，能够作为安全的Web服务器或反向代理使用。

server {

  listen 443 ssl;

  ssl_certificate /path/to/fullchain.pem; # 证书路径

  ssl_certificate_key /path/to/privatekey.pem; # 私钥路径

  ssl_protocols TLSv1.2 TLSv1.3; # 支持的SSL协议

}

搭建 Nginx 服务

如何安装？

在 Linux 系统中，可以使用包管理器来安装 Nginx。例如，在基于 Debian 的系统上，可以使用 apt：

sudo apt update

sudo apt install nginx

在基于 Red Hat 的系统上，可以使用 yum 或 dnf：

sudo yum install epel-release

sudo yum install nginx

在安装完成后，通常可以通过以下命令启动 Nginx 服务：

sudo systemctl start nginx

设置开机自启动：

sudo systemctl enable nginx

启动成功后，在浏览器输入服务器 ip 地址或者域名，如果看到 Nginx 的默认欢迎页面，说明 Nginx 运行成功。

常用命令有哪些

在日常的服务器管理和运维中，使用脚本来管理 Nginx 是很常见的。这可以帮助自动化一些常规任务，如启动、停止、重载配置等。以下是一些常用的 Nginx 脚本命令，这些脚本通常用于 Bash 环境下：

其他常用的配合脚本命令：

。。。还有哪些常用命令，评论区一起讨论下！

配置文件构成（🔥核心重点，一定要了解）

Nginx配置文件主要由指令组成，这些指令可以分布在多个上下文中，主要上下文包括：

worker_processes auto;   # worker_processes定义Nginx可以启动的worker进程数，auto表示自动检测 



# 定义Nginx如何处理连接 

events {   

    worker_connections 1024;  # worker_connections定义每个worker进程可以同时打开的最大连接数 

}  

  

# 定义HTTP服务器的参数  

http {  

    include mime.types;  # 引入mime.types文件，该文件定义了不同文件类型的MIME类型  

    default_type application/octet-stream;  # 设置默认的文件MIME类型为application/octet-stream  

    sendfile on;  # 开启高效的文件传输模式  

    keepalive_timeout 65;  # 设置长连接超时时间  



    # 定义一个虚拟主机  

    server {  

        listen 80;  # 指定监听的端口

        server_name localhost;  # 设置服务器的主机名，这里设置为localhost  

        

        # 对URL路径进行配置  

        location / {  

            root /usr/share/nginx/html;  # 指定根目录的路径  

            index index.html index.htm;  # 设置默认索引文件的名称，如果请求的是一个目录，则按此顺序查找文件  

        }  



        # 错误页面配置，当请求的文件不存在时，返回404错误页面  

        error_page 404 /404.html;  



        # 定义/40x.html的位置  

        location = /40x.html {  

            # 此处可以配置额外的指令，如代理、重写等，但在此配置中为空  

        }  



        # 错误页面配置，当发生500、502、503、504等服务器内部错误时，返回相应的错误页面  

        error_page 500 502 503 504 /50x.html;  



        # 定义/50x.html的位置  

        location = /50x.html {  

            # 同上，此处可以配置额外的指令  

        }  

    }  

}

这个配置文件设置了Nginx监听80端口，使用root指令指定网站的根目录，并为404和50x错误页面提供了位置。其中，user和worker_processes指令在main上下文中，events块定义了事件处理配置，http块定义了HTTP服务器配置，包含一个server块，该块定义了一个虚拟主机，以及两个location块，分别定义了对于404和50x错误的处理。

进入正题，详细看下如何配置

打开 Nginx 配置世界大门

下面这段是 Nginx 配置定义了一个服务器块（server block），它指定了如何处理发往特定域名的 HTTP 请求。

server {

    listen 80;  # 监听80端口，HTTP请求的默认端口

    client_max_body_size 100m;  # 设置客户端请求体的最大大小为100MB

    index index.html;  # 设置默认的索引文件为index.html

    root /user/project/admin;  # 设置Web内容的根目录为/user/project/admin



    # 路由配置，处理所有URL路径

    location ~ /* {

        proxy_pass http://127.0.0.1:3001;  # 将请求代理到本机的3001端口

        proxy_redirect off;  # 关闭代理重定向



        # 设置代理请求头，以便后端服务器可以获取客户端的原始信息

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;



        # 定义代理服务器失败时的行为，如遇到错误、超时等，尝试下一个后端服务器

        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;

        proxy_max_temp_file_size 0;  # 禁止代理临时文件写入



        # 设置代理连接、发送和读取的超时时间

        proxy_connect_timeout 90;

        proxy_send_timeout 90;

        proxy_read_timeout 90;



        # 设置代理的缓冲区大小

        proxy_buffer_size 4k;

        proxy_buffers 4 32k;

        proxy_busy_buffers_size 64k;

        proxy_temp_file_write_size 64k;

    }



    # 对图片文件设置缓存过期时间，客户端可以在1天内使用本地缓存

    location ~ .*.(gif|jpg|jpeg|png|swf)$ {

        expires 1d; 

    }



    # 对JavaScript和CSS文件设置缓存过期时间，客户端可以在24小时内使用本地缓存

    location ~ .*.(js|css)?$ {

        expires 24h;

    }



    # 允许访问/.well-known目录下的所有文件，通常用于WebFinger、OAuth等协议

    location ~ /.well-known {

        allow all;

    }



    # 禁止访问隐藏文件，即以点开头的文件或目录

    location ~ /. {

        deny all;

    }



    # 指定访问日志的路径，日志将记录在/user/logs/admin.log文件中

    access_log /user/logs/admin.log;

}

注意：Nginx 支持使用正则表达式来匹配 URI，这极大地增强了配置的灵活性。在 Nginx 配置中，正则表达式通过 ~ 来指定。

例如，location ~ /* 可以匹配所有请求。另一个例子是 location ~ .*.(gif|jpg|jpeg|png|swf)$，这个表达式用于匹配以 gif、jpg、jpeg、png 或 swf 这些图片文件扩展名结尾的请求。

Nginx 配置实战（🔥可以复制，直接拿来使用）

以下是一些常见的 Nginx 配置实战案例：

1、静态资源服务：前端web

server {

    listen 80;

    server_name example.com;

    location / {

        root /path/to/your/static/files;

        index index.html index.htm;

    }

    location ~* \.(jpg|png|gif|jpeg)$ {

        expires 30d;

        add_header Cache-Control "public";

    }

}

在这个案例中，Nginx 配置为服务静态文件，如 HTML、CSS、JavaScript 和图片等。通过设置 root 指令，指定了静态文件的根目录。同时，对于图片文件，通过 expires 指令设置了缓存时间为 30 天，减少了服务器的负载和用户等待时间。

2、反向代理

server {

    listen 80;

    server_name api.example.com;

    location / {

        proxy_pass http://backend;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

}

这个案例展示了如何配置 Nginx 作为反向代理服务器。当客户端请求 api.example.com 时，Nginx 会将请求转发到后端服务器集群。通过设置 proxy_set_header，可以修改客户端请求的头部信息，确保后端服务器能够正确处理请求。

3、负载均衡

http {

    upstream backend {

        server backend1.example.com;

        server backend2.example.com;

        server backend3.example.com;

    }

    server {

        listen 80;

        server_name example.com;

        location / {

            proxy_pass http://backend;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        }

    }

}

在这个负载均衡的案例中，Nginx 将请求分发给多个后端服务器。通过 upstream 指令定义了一个服务器组，然后在 location 块中使用 proxy_pass 指令将请求代理到这个服务器组。Nginx 支持多种负载均衡策略，如轮询（默认）、IP 哈希等。

4、HTTPS 配置

server {

    listen 443 ssl;

    server_name example.com;

    ssl_certificate /path/to/your/fullchain.pem;

    ssl_certificate_key /path/to/your/private.key;

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';

    ssl_prefer_server_ciphers on;

    location / {

        root /path/to/your/https/static/files;

        index index.html index.htm;

    }

}

这个案例展示了如何配置 Nginx 以支持 HTTPS。通过指定 SSL 证书和私钥的路径，以及设置 SSL 协议和加密套件，可以确保数据传输的安全。同时，建议使用 HTTP/2 协议以提升性能。

5、安全防护

server {

    listen 80;

    server_name example.com;

    location / {

        # 防止 SQL 注入等攻击

        rewrite ^/(.*)$ /index.php?param=$1 break;

        # 限制请求方法，只允许 GET 和 POST

        if ($request_method !~ ^(GET|POST)$ ) {

            return 444;

        }

        # 防止跨站请求伪造

        add_header X-Frame-Options "SAMEORIGIN";

        add_header X-Content-Type-Options "nosniff";

        add_header X-XSS-Protection "1; mode=block";

    }

}

通过 rewrite 指令，可以防止一些常见的 Web 攻击，如 SQL 注入。这种限制请求方法，可以减少服务器被恶意利用的风险。同时，添加了一些 HTTP 头部来增强浏览器安全，如防止点击劫持和跨站脚本攻击（XSS）等。

Nginx 深入学习-负载均衡

在负载均衡的应用场景中，Nginx 通常作为反向代理服务器，接收客户端的请求并将其分发到一组后端服务器。这样做不仅可以分散负载、提升网站的响应速度，更能提高系统的可用性。

健康检查

Nginx 能够监测后端服务器的健康状态。如果服务器无法正常工作，Nginx 将自动将请求重新分配给其他健康的服务器。

http {

    upstream myapp1 { # 定义了后端服务器组

        server srv1.example.com;

        server srv2.example.com;

        server srv3.example.com;

        

        # 健康检查配置。

        # 每10秒进行一次健康检查，如果连续3次健康检查失败，则认为服务器不健康；

        # 如果连续2次健康检查成功，则认为服务器恢复健康。

        check interval=10s fails=3 passes=2;

    }



    server {

        listen 80;



        location / {

            proxy_pass http://myapp1;

            proxy_set_header Host $host;

            proxy_set_header X-Real-IP $remote_addr;

            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        }

    }

}

check interval=10s fails=3 passes=2; 这样的配置语法在开源版本的 NGINX 上是不支持的。这是 ngx_http_upstream_check_module 模块的特有语法，而该模块不包含在 NGINX 的开源版本中，需要自行下载、编译和安装。该模块是开源免费的，具体详情请参见 ngx_http_upstream_check_module 文档。

Nginx 会定期向定义的服务器发送健康检查请求。如果服务器响应正常，则认为服务器健康；如果服务器没有响应或者响应异常，则认为服务器不健康。当服务器被标记为不健康时，Nginx 将不再将请求转发到该服务器，直到它恢复健康。

负载均衡算法

Nginx 支持多种负载均衡算法，可以适应不同的应用场景。以下是几种常见的负载均衡算法的详细说明和示例：

1、Weight轮询（默认）：权重轮询算法是 Nginx 默认的负载均衡算法。它按顺序将请求逐一分配到不同的服务器上。通过设置服务器权重（weight）来调整不同服务器上请求的分配率。

upstream backend {

  server backend1.example.com weight=3; # 设置backend1的权重为3

  server backend2.example.com; # backend2的权重为默认值1

  server backend3.example.com weight=5; # 设置backend3的权重为5

}

如果某一服务器宕机，Nginx会自动将该服务器从队列中剔除，请求代理会继续分配到其他健康的服务器上。

2、IP Hash 算法： 根据客户端IP地址的哈希值分配请求，确保客户端始终连接到同一台服务器。

upstream backend {

  ip_hash; # 启用IP哈希算法

  server backend1.example.com;

  server backend2.example.com;

}

根据客户端请求的IP地址的哈希值进行匹配，将具有相同IP哈希值的客户端分配到指定的服务器。这样可以确保同一客户端的请求始终被分配到同一台服务器，有助于保持用户的会话状态。

3、fair算法： 根据服务器的响应时间和负载来分配请求。

upstream backend {

  fair; # 启用公平调度算法

  server backend1.example.com;

  server backend2.example.com;

  server backend3.example.com;

}

它结合了轮询和IP哈希的优点，但Nginx默认不支持公平调度算法，需要安装额外的模块（upstream_fair）来实现。

4、URL Hash 算法： 根据请求的 URL 的哈希值分配请求，每个请求的URL会被分配到指定的服务器，有助于提高缓存效率。

upstream backend {

  hash $request_uri; # 启用URL哈希算法

  server backend1.example.com;

  server backend2.example.com;

}

# 根据请求的URL哈希值来决定将请求发送到backend1还是backend2。

这种方法需要安装Nginx的hash软件包。

开源模块

Nginx拥有丰富的开源模块，有很多还有待我们探索，除了一些定制化的需求需要自己开发，大部分的功能都有开源。大家可以在 NGINX 社区、GitHub 上搜索 "nginx module" 可以找到。

总结

虽然前端人员可能不经常直接操作 Nginx，但了解其基本概念和简单的配置操作是必要的。这样，在需要自行配置 Nginx 的情况下，前端人员能够知晓如何进行基本的设置和调整。

守护线程

Signal Catcher线程

Signal Catcher是一个守护线程，用于捕获 SIGQUIT, SIGUSR1 信号,并采取相应的行为。

Android系统中，由Zygote孵化而来的子进程，包含system_server进程和各种APP进程都存在一个Signal Catcher线程，但是Zygote进程本身没有这个线程。

在Process类中有SIGQUIT，SIGUSR1 的定义：

    public static final int SIGNAL_QUIT = 3;

    public static final int SIGNAL_KILL = 9;

    public static final int SIGNAL_USR1 = 10;

当前进程的Signal Catcher线程接收到信号SIGNAL_QUIT，则挂起进程中的所有线程并DUMP所有线程的状态。

当前进程的Signal Catcher线程接收到信号SIGNAL_USR1，则触发进程强制执行GC操作。

发送信号的方式：

Process.sendSignal(android.os.Process.myPid(), Process.SIGNAL_QUIT);

Process.sendSignal(android.os.Process.myPid(), Process.SIGNAL_USR1);

当我们直接在代码中调用上诉代码会发生什么？

Process.SIGNAL_USR1:

I/Process: Sending signal. PID: 12363 SIG: 10

I/etease.popo.ap: Thread[3,tid=12373,WaitingInMainSignalCatcherLoop,Thread*=0x793d816400,peer=0x13700020,"Signal Catcher"]: reacting to signal 10

I/etease.popo.ap: SIGUSR1 forcing GC (no HPROF) and profile save

I/etease.popo.ap: Explicit concurrent copying GC freed 18773(4MB) AllocSpace objects, 7(140KB) LOS objects, 68% free, 2MB/8MB, paused 130us total 13.633ms

Process.SIGNAL_QUIT

I/Process: Sending signal. PID: 12812 SIG: 3

I/etease.popo.ap: Thread[3,tid=12823,WaitingInMainSignalCatcherLoop,Thread*=0x793d816400,peer=0x148051b0,"Signal Catcher"]: reacting to signal 3

I/etease.popo.ap: Wrote stack traces to '[tombstoned]'

RenderThread 渲染线程

Android 5.0之后新增的一个线程，用来协助UI线程进行图形绘制。所有的GL命令执行都放在这个线程上。渲染线程在RenderNode中存有渲染帧的所有信息，并监听VSync信号，因此可以独立做一些属性动画。

在清单文件APP中添加：android:hardwareAccelerated="false"
启动APP将会不存在渲染线程；硬件加速在Android中试默认开启的。

Render Thread在运行时主要是做以下两件事情：

• Task Queue的任务，这些Task一般就是由MainThread发送过来的，例如，MainThread通过发送一个DrawFrameTask给RenderThread的TaskQueue中，请求RenderThread渲染窗口的下一帧。


• PendingRegistrationFrameCallbacks列表的IFrameCallback回调接口。每一个IFrameCallback回调接口代表的是一个动画帧，这些动画帧被同步到Vsync信号到来由RenderThread自动执行。具体来说，就是每当Vsync信号到来时，就将一个类型为DispatchFrameCallbacks的Task添加到RenderThread的TaskQueue去等待调度。一旦该Task被调度，就可以在RenderThread中执行注册在PendingRegistrationFrameCallbacks列表中的IFrameCallback回调接口了。

FinalizerDaemon 析构守护线程

对于重写成员函数finailze的对象，他们被GC决定回收时，并没有马上被回收，而是被放入到一个队列中，等待FinalizerDaemon守护线程去调用他们的成员函数finalize，然后再被回收。

FinalizerWatchdogDaemon 析构监护守护线程。

用来监控FinalizerDaemon线程的执行。一旦检测哪些重写了成员函数finalize的对象在执行成员函数finalize时超出一定的时候，那么就会退出VM。

ReferenceQueueDaemon 引用队列守护线程

我们知道在创建引用对象的时候，可以关联一个队列。当被引用对象引用的对象被GC回收的时候呀，被引用对象就会呗加入到其创建时关联的队列中去，这个加入队列的操作就是由ReferenceQueueDaemon守护线程来完成的。这样应用程序就可以知道哪些被引用对象引用的对象已经被回收了。

HeapTrimmerDaemon 堆裁剪守护线程

用于执行裁剪堆的操作，也就是用来将哪些空闲的堆内存归还给系统。

HeapTaskDaemon 线程

Android每个进程都有一个HeapTaskDaemon线程，在该线程内进行GC操作。
HeapTaskDaemon 继承自 Daemon 对象。Daemon 对象实际是一个Runnale，并且内部会创建一个线程，用于执行当前这个 Daemon unnable，这个内部线程的线程名就叫 HeapTaskDaemon。

private static class HeapTaskDaemon extends Daemon {

        private static final HeapTaskDaemon INSTANCE = new HeapTaskDaemon();



        HeapTaskDaemon() {

            super("HeapTaskDaemon");

        }



        // Overrides the Daemon.interupt method which is called from Daemons.stop.

        public synchronized void interrupt(Thread thread) {

            VMRuntime.getRuntime().stopHeapTaskProcessor();

        }



        @Override public void runInternal() {

            synchronized (this) {

                if (isRunning()) {

                  // Needs to be synchronized or else we there is a race condition where we start

                  // the thread, call stopHeapTaskProcessor before we start the heap task

                  // processor, resulting in a deadlock since startHeapTaskProcessor restarts it

                  // while the other thread is waiting in Daemons.stop().

                  VMRuntime.getRuntime().startHeapTaskProcessor();

                }

            }

            // This runs tasks until we are stopped and there is no more pending task.

            VMRuntime.getRuntime().runHeapTasks();

        }

    }

Binder 线程

每个APP进程在启动之后会创建一个binder线程池，用于相应IPC客户端的请求。

例如APP与AMS等服务之间可以通过IPC双向通信，当APP作为服务端的时候，就需要通过Binder线程相应来自AMS的请求。一个Server进程中有一个最大的Binder线程数限制，默认为16个binder线程。

与系统服务通信或者自行实现多进程Binder通信大致需要注意一下几点：

• 与系统通信的方法，建议使用try cache进行防护，防止App出现崩溃。


• 需要注意调用频率，部分API调用频率过快响应会比较慢，从而导致主线程卡顿甚至ANR。

主线程

主线程也较UI线程。

这个线程作为Android 开发都比较熟悉。

三方线程

OkHttp相关

如果你使用OkHttp作为网络请求库，那么工程中会有以下几类线程

OkHttp Dispatcher

用于实际执行HTTP请求

  @get:Synchronized

  @get:JvmName("executorService") val executorService: ExecutorService

    get() {

      if (executorServiceOrNull == null) {

        executorServiceOrNull = ThreadPoolExecutor(0, Int.MAX_VALUE, 60, TimeUnit.SECONDS,

            SynchronousQueue(), threadFactory("$okHttpName Dispatcher", false))

      }

      return executorServiceOrNull!!

    }

OkHttp TaskRunner

4.x版本引入，用于管理和调度内部任务

  companion object {

    @JvmField

    val INSTANCE = TaskRunner(RealBackend(threadFactory("$okHttpName TaskRunner", daemon = true)))



    val logger: Logger = Logger.getLogger(TaskRunner::class.java.name)

  }

OkHttp ConnectionPool

负责清理和回收无用的连接池

  private val cleanupTask = object : Task("$okHttpName ConnectionPool") {

    override fun runOnce() = cleanup(System.nanoTime())

  }

Okio Watchdog

OkHttp中使用Watchdog来处理超时逻辑

  private class Watchdog internal constructor() : Thread("Okio Watchdog") {

    init {

      isDaemon = true

    }



    override fun run() {

      while (true) {

        try {

          var timedOut: AsyncTimeout? = null

          synchronized(AsyncTimeout::class.java) {

            timedOut = awaitTimeout()



            // The queue is completely empty. Let this thread exit and let another watchdog thread

            // get created on the next call to scheduleTimeout().

            if (timedOut === head) {

              head = null

              return

            }

          }



          // Close the timed out node, if one was found.

          timedOut?.timedOut()

        } catch (ignored: InterruptedException) {

        }

      }

    }

  }

Glide相关

如果你使用Glide加载图片，那么工程中会有以下几类线程

"glide-source-thread-x"

用于从网络、文件系统或其他数据源中加载原始图像数据

  public static GlideExecutor.Builder newSourceBuilder() {

    return new GlideExecutor.Builder(/* preventNetworkOperations= */ false)

        .setThreadCount(calculateBestThreadCount())

        .setName(DEFAULT_SOURCE_EXECUTOR_NAME);

  }

"glide-disk-cache-thread-x"

用于从缓存中读取数据

  public static GlideExecutor.Builder newDiskCacheBuilder() {

    return new GlideExecutor.Builder(/* preventNetworkOperations= */ true)

        .setThreadCount(DEFAULT_DISK_CACHE_EXECUTOR_THREADS)

        .setName(DEFAULT_DISK_CACHE_EXECUTOR_NAME);

  }

source-unlimited

  public static GlideExecutor newUnlimitedSourceExecutor() {

    return new GlideExecutor(

        new ThreadPoolExecutor(

            0,

            Integer.MAX_VALUE,

            KEEP_ALIVE_TIME_MS,

            TimeUnit.MILLISECONDS,

            new SynchronousQueue<Runnable>(),

            new DefaultThreadFactory(

                new DefaultPriorityThreadFactory(),

                DEFAULT_SOURCE_UNLIMITED_EXECUTOR_NAME,

                UncaughtThrowableStrategy.DEFAULT,

                false)));

  }

animation

用于执行动画

  public static GlideExecutor.Builder newAnimationBuilder() {

    int maximumPoolSize = calculateAnimationExecutorThreadCount();

    return new GlideExecutor.Builder(/* preventNetworkOperations= */ true)

        .setThreadCount(maximumPoolSize)

        .setName(DEFAULT_ANIMATION_EXECUTOR_NAME);

  }

ARouter相关

如果你使用ARouter作为路由

ARouter task pool No.x , thread No.X

创建位置

    public static DefaultPoolExecutor getInstance() {

        if (null == instance) {

            synchronized (DefaultPoolExecutor.class) {

                if (null == instance) {

                    instance = new DefaultPoolExecutor(

                            INIT_THREAD_COUNT,

                            MAX_THREAD_COUNT,

                            SURPLUS_THREAD_LIFE,

                            TimeUnit.SECONDS,

                            new ArrayBlockingQueue<Runnable>(64),

                            new DefaultThreadFactory());

                }

            }

        }

        return instance;

    }

另外ARouter也为开发者提供了使用自己线程池的接口：

    static synchronized void setExecutor(ThreadPoolExecutor tpe) {

        executor = tpe;

    }

三方库总结

关于三方库中的线程池这里仅列举了几个库。如果你的工程中含有大量的三方库，我详细也会存在大量的工作线程。

一些三方库会提供接口允许开发者将其替换成工程内部统一维护的线程池，这样可以做到工程中线程的收敛。笔者遇到最离谱的应该是腾讯X5浏览器，由另外一个小组的同事引入到项目中，集成后发现其引入了大量的线程（大概几十个）。

其他

我个人不太喜欢发这些纯概念的东西，更喜欢总结一些在工程中遇到的问题、对应的解决方案以及思考。后面考虑尽量少发这类笔记，多输出一些思考。

前言

又是无聊的一天，逛GitHub的时候发现一个给女朋友做了一个互动微信小程序，据说女朋友更爱自己了，所以当晚。。。。给自己做了丰盛的晚餐，我当即点开立马开发粘贴复制起来，想到做的小程序可以和未来的女朋友增进感觉，越加猩粪。。。

回到正题，这个库有1.1k的star，推荐新人入坑原生小程序的可以学习

项目地址：github.com/UxxHans/Rai…

云开发情侣互动小程序（做任务，攒积分，换商品）

这是使用云开发能力构建的情侣互动小程序，可以跟女朋友互动哦，其中使用了云开发基础能力的使用：

• 数据库：对文档型数据库进行读写和管理


• 云函数：在云端运行的代码，开发者只需编写业务逻辑代码

使用逻辑

打个比方:

• 女朋友发布任务->女朋友来做任务->做完后由你来确认完成->女朋友收到积分


• 你发布商品(洗碗券)->女朋友使用积分购买->商品进入到女朋友的库存->女朋友拿着洗碗券叫你洗碗->你洗碗->女朋友将物品(洗碗券)标记为已使用(不可逆)


• 这样做的原因是 不想给任何一方能自说自话 增加自己或者对方积分的能力[点击完成任务的人不能是获得积分的人也不能是自己]

版本新增

• 将所有非云函数的云逻辑封装为云函数


• 新增了仓库系统，购买了的商品会存入仓库，然后再被使用


• 新增了搜索框，可以搜索物品和任务


• 新增了滑动窗，可以自动播放显示多张图片


• 新增了商品和任务预设，添加商品或任务可以使用预设，非常迅速


• 将新增按钮变为可拖拽的页面悬浮按钮


• 购买，上架，新建任务的时间都会被记录并显示


• 取消了点击左边圆圈来完成或者购买，统一改为左滑菜单


• 左滑菜单统一用图标显示，更加精简


• 使用特效升级了详细信息页面与添加页面的美观度


• 添加任务或物品界面积分文本框改为滑块


• 在商城添加了顶栏显示积分，更直观


• 使用表情符号简单的增加了美感

效果图与动画

部署方式

• 在这里注册小程序开发者: mp.weixin.qq.com/cgi-bin/wx


• 在这里登录开发者账号: mp.weixin.qq.com/

• 登录之后先在主页完成小程序信息和类目


• 然后可以在管理中的版本管理与成员管理中发布小程序体验版并邀请对象使用

• 随后可以在开发中的开发工具里下载微信开发者工具


• 打开微信开发工具->登录->导入我的文件夹-进入工具


• 在左上角五个选项中选择云开发->按照提示开通云开发(这里可以选择免费的，不过限量，我开发用的多，6块够用了)

• 进入后点击数据库->在集合名称添加四个集合：MarketList, MissionList, StorageList, UserList


• 之前使用过上一个版本的，需要清空所有数据，因为字段结构不一样

• 在UserList中添加两个默认记录, 在两个记录中分别添加两个字段:

字段 = _openid | 类型 = string | 值 = 先不填

字段 = credit | 类型 = number | 值 = 0

• 打开云开发的控制台的概览选项->复制环境ID


• 打开 miniprogram/envList.js 将内容全部替换成如下，注意替换环境ID

module.exports = {

  envList: [{

    envId:'上述步骤中你获得的环境ID (保留单引号)'

  }]

}

• 右键点击 cloudfunctions 中的每个文件夹并选择云函数云端安装依赖上传 (有点麻烦但是这是一定要做的)

• 如果云开发里面的云函数页面是这样的就是成功了

• 没有安装npm或者NodeJs, 需要先在这里安装: nodejs.org/dist/v16.15…


• 安装好的，就直接运行cloudfunctions/Install-WX-Server-SDK.bat


• 不成功的话可以在命令行输入 npm install --save wx-server-sdk@latest


• 然后创建体验版小程序->通过开发者账号分享到女朋友手机上(要先登录小程序开发者账号)


• 在两个手机上运行小程序->分别在两个手机上的小程序里新建任务


• 然后回到云开发控制台的missionlist数据库集合->找自己和女朋友的_openid变量并记录


• 把这两个记录下来的_openid拷贝到云开发控制台UserList数据集合里刚刚没填的_openid变量中


• 把这两个记录下来的_openid拷贝到miniprogram/app.js里的_openidA和_openidB的值里(A是卡比，B是瓦豆)


• 在miniprogram/app.js里把userA和userB改成自己和女朋友的名字


• 然后再试试看是不是成功了! (别忘了任务和物品左滑可以完成和购买)


• 消息提醒功能：


• 参考blog.csdn.net/hell_orld/a…allsobaiduend~default-2-110675777-null-null.142^v87^insert_down28v1,239^v2^insert_chatgpt&utm_term=%E5%BE%AE%E4%BF%A1%E5%B0%8F%E7%A8%8B%E5%BA%8F%E9%80%9A%E7%9F%A5%E4%BA%91%E5%BC%80%E5%8F%91&spm=1018.2226.3001.4187配置自己想要的模板\


• 在miniprogram/pages/MainPage/index.js和miniprogram/pages/MissionAdd/index.js里把模板号换成自己想要的模板号


• 在cloudfunctions/information/index.js里把UserA和UserB的openid值进行修改就能使用消息提醒功能了

• 别忘了最后点击右上角上传->然后在开发者账号上设置小程序为体验版->不用去发布去审核

• 最后如果有兴趣可以继续深入开发, 开发文档: developers.weixin.qq.com/miniprogram…

旧版效果图

一、背景

笔者前段时间开发了一款非常有意思的项目，已知在同一个局域网下有两款App分别运行在不同的设备上，业务上两款App分别具有不同的功能，同时两款App需要支持互相通信。后面我们称两款设备上的两款App一个为Server，一个为Client。

基于此我们需要考虑以下几点

• 如何发现对方


• 两款App如何通信


• 通信协议如何选择

二、发现对方

在局域网中查找识别我们可以基于DNS-SD协议。

1、DNS-SD协议介绍

DNS-SD（Domain Name System - Service Discovery）是一种用于在局域网（Local Area Network，LAN）中发现服务的协议。它使用DNS协议扩展了域名系统（Domain Name System，DNS）的功能，使得客户端能够在局域网中查找特定类型的服务，并获取有关该服务的信息。

在Android 中也有对应的Api可以使用：NsdManager。
NsdManager主要实现三个功能：

• 注册


• 发现


• 解析

其中一台设备作为服务端（即上面的Server App）通过NsdManager注册服务，提供自己的IP地址与端口号，同时可以提供用于标识自己的信息，例如设备ID。当一个局域网中有多台服务时，客户端在发现服务后，可以基于标识信息确认是否为自己需要找到的服务端。

另一台设备作为客户端（即上面的Client App），通过NsdManager的发现接口去发现服务。发现服务之后，再调用解析接口，获取到对应的信息，如服务端的IP地址、端口号、设备标识信息等。

详细的官方介绍地址：developer.android.com/reference/a…

2、注册

作为服务端的Server App，通过NsdManager注册。

NsdManager nsdManager = (NsdManager) context.getSystemService(Context.NSD_SERVICE);

NsdServiceInfo serviceInfo = new NsdServiceInfo();

serviceInfo.setServiceName(ServiceName);

serviceInfo.setServiceType(ServiceType);

int localPort = getLocalPort();

serviceInfo.setPort(localPort);

serviceInfo.setAttribute(Attribute_UUID, UuidManager.INSTANCE.getUUID());

String ipAddress = LocalIpUtils.getIPAddress();

serviceInfo.setAttribute(Attribute_IP, ipAddress);

nsdManager.registerService(serviceInfo, NsdManager.PROTOCOL_DNS_SD, new NsdManager.RegistrationListener() {

    @Override

    public void onRegistrationFailed(NsdServiceInfo nsdServiceInfo, int i) {

        //异常上报

    }



    @Override

    public void onUnregistrationFailed(NsdServiceInfo nsdServiceInfo, int i) {}



    @Override

    public void onServiceRegistered(NsdServiceInfo nsdServiceInfo) {

        //注册成功

    }



    @Override

    public void onServiceUnregistered(NsdServiceInfo nsdServiceInfo) {}

});

3、发现

Client App，调用NsdManager#discoverServices()接口去发现服务。

NsdManager nsdManager = (NsdManager) context.getSystemService(Context.NSD_SERVICE);

discoveryListener = new NsdManager.DiscoveryListener() {

    @Override

    public void onStartDiscoveryFailed(String s, int i) {}



    @Override

    public void onStopDiscoveryFailed(String s, int i) {}



    @Override

    public void onDiscoveryStarted(String s) {}



    @Override

    public void onDiscoveryStopped(String s) {}



    @Override

    public void onServiceFound(NsdServiceInfo nsdServiceInfo) {}



    @Override

    public void onServiceLost(NsdServiceInfo nsdServiceInfo) {}

};

nsdManager.discoverServices(NsdServer.ServiceType, NsdManager.PROTOCOL_DNS_SD, discoveryListener);

4、解析

Client App 收到onServcieFound回调之后，就可以调用解析接口解析数据了

nsdManager.resolveService(nsdServiceInfo, new NsdManager.ResolveListener() {

    @Override

    public void onServiceResolved(NsdServiceInfo nsdServiceInfo) {

        Map<String, byte[]> attributes = nsdServiceInfo.getAttributes();

    }



    @Override

    public void onResolveFailed(NsdServiceInfo nsdServiceInfo, int i) {}

});

二、TCP通信

发现设备之后，我们要考虑两台设备要如何通信。此时我们可以有两套方案，分别是HTTP以及TCP。

HTTP

使用HTTP的话，就是在Server App上启动一个HTTP服务，我们可以预定义一些接口用于和Client来通信。
优点是比较简单，缺点是Server App没有办法主动通知Client App。

TCP

直接使用TCP协议的话，我们可以考虑选择一个支持TCP通信的框架，自定义一个简易的通信协议。优点是客户端与服务端可以互相通信，满足我们的需求。缺点是相对复杂一些。

在我们的项目中，我们有两台设备交互通信的需求，所以选择了TCP协议。

1、TCP通信库的选择

在我们的项目中使用了Netty作为TCP通信框架。关于Netty其大名鼎鼎，网络上的分析文章一大把，这里就不详细介绍了。Netty在国内有一位步道的大神名为李林峰（在华为工作），有兴趣的同学可以去看看大神的书。

2、简易的TCP协议设计

由于业务比较简单，所以这里我们将TCP通信协议进行简化。整体协议大致如下：[Int][String]。

其中Int用于指定后面String字符串长度，我们可以基于这个Int来处理拆包、粘包的问题，这个逻辑后面详细介绍。String可以是JSON结构，可以依据业务来定义JSON中字段。

3、TCP服务端

使用Netty实现TCP服务端大致代码

bossGr0up = new NioEventLoopGr0up();

workerGr0up = new NioEventLoopGr0up();

//构建引导程序

mBootstrap = new ServerBootstrap();

//设置EventGr0up

mBootstrap.group(bossGr0up, workerGr0up);

//设置Channel

mBootstrap.channel(NioServerSocketChannel.class);

mBootstrap.option(ChannelOption.SO_BACKLOG, 128);

//设置的好处是禁用Nagle算法。表示不延迟立即发送

//这个算法试图减少TCP包的数量和结构性开销，将多个较小的包组合较大的包进行发送。

//这个算法收TCP延迟确认影响，会导致相继两次向链接发送请求包。

mBootstrap.option(ChannelOption.TCP_NODELAY, false);

mBootstrap.option(ChannelOption.SO_KEEPALIVE, true);

mBootstrap.childHandler(new CustomChannelInitializer());

channelFuture = mBootstrap.bind(inetPort).sync();

以上TCP服务就启动了。

4、TCP客户端

使用Netty实现TCP客户端大致代码：

初始化

//构建线程池

mGr0up = new NioEventLoopGr0up();

//构建引导程序

mBootstrap = new Bootstrap();

//设置EventGr0up

mBootstrap.group(mGr0up);

//设置Channel

mBootstrap.channel(NioSocketChannel.class);

//设置的好处是禁用Nagle算法。表示不延迟立即发送

//这个算法试图减少TCP包的数量和结构性开销，将多个较小的包组合较大的包进行发送。

//这个算法收TCP延迟确认影响，会导致相继两次向链接发送请求包。

mBootstrap.option(ChannelOption.TCP_NODELAY, false);

mBootstrap.option(ChannelOption.SO_KEEPALIVE, true);

mBootstrap.remoteAddress(ip.getIp(), ip.getPort());

mBootstrap.handler(new CustomChannelInitializer());

建立连接

ChannelFuture channelFuture = mBootstrap.connect();

channelFuture.addListener(new FutureListener() {

    @Override

    public void operationComplete(Future future) {

        final boolean isSuccess = future.isSuccess();

        writeLog("operation complete future.isSuccess: " + isSuccess);

    }

});

断开连接

public void disConnect(boolean onPurpose) {

    try {

        if (mGr0up != null) {

            mGr0up.shutdownGracefully();

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

    try {

        if (mChannel != null) {

            mChannel.close();

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

    try {

        if (mChannelHandlerContext != null) {

            mChannelHandlerContext.close();

        }

    } catch (Exception e) {

        e.printStackTrace();

    }

}

我们可以在operationComplete()方法中，确认建立连接成功。

ChannelInitializer

为了让更多协议和其他各种方式处理数据，Netty有了Handler组件。Handler就是为了处理Netty里面的置顶事件或一组事件。 ChannelInitializer 的作用就是将Handler 添加到ChannelPipeline中。当你发送或收到消息的时候，这些Handler就决定怎么处理你的数据。

public class CustomChannelInitializer extends ChannelInitializer<SocketChannel> {



    @Override

    protected void initChannel(SocketChannel socketChannel) {

        ChannelPipeline pipeline = socketChannel.pipeline();

        mCustomDecoder = new CustomDecoder();

        mCustomEncoder = new CustomEncoder();

        mCustomHandler = new CustomHandler();

        

        pipeline.addLast(mCustomDecoder);

        pipeline.addLast(mCustomEncoder);

        pipeline.addLast(mCustomHandler);

    }



    @Override

    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {

        super.handlerAdded(ctx);

    }



    @Override

    public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {

        super.exceptionCaught(ctx, cause);

    }

}

ChannelPipeline 是一个管道，Handler就是里面一层一层要对数据进行处理的事件。所有的Handler都一个顶层接口ChannelHandler。ChannelHandler有两个子接口：

• ChannelInboundHandler


• ChannelOutboundHandler

Netty中数据流有2个方向：

• 数据进（应用收到消息）的时候与ChannelInboundHandler有关。


• 数据出（应用发出数据）的时候与ChannelOutboundHandler有关。

为了将数据从一端发送到另一端，一般都会有一个或多个ChannelHandler用各种方式对数据进行操作。 决定这些Handler以一种特定的顺序处理数据的是ChannelPipeline。

ChannelInboundHandler与ChannelOutboundHandler可以混在同一个ChannelPipeline里面。当应用收到数据时，首先从ChannelPipeline的头部进入到一个ChannelInboundHandler 。第一个ChannelInboundHandler处理后传给下一个ChannelInboundHandler。 然后ChannelPipeline中没有其他的ChannelInboundHandler 了数据就会到达ChannelPipeline的尾部，也就是应用对数据的处理已经完成了。

数据流出的过程是返过来的，首先从ChannelPipeline的尾部开始进入到最后一个ChannelOutboundHandler，最后一个ChannelOutboundHandler处理后，传给前面一个ChannelOutboundHandler。 和进不同的，进是从前到后，而出是从后到前。没有多余的ChannelOutboundHandler的时候，数据进入实际网络中传输，触发一些IO操作。

一旦一个ChannelHandler被添加到ChannelPipeline中，它就会获得一个ChannelHandlerContext。一般情况下，获得这个对象并持有它是安全的， 不过在数据包协议的时候不一样安全，例如UDP协议。 在Netty中有两种发送数据的方式。你可以写到Channel中或者使用ChannelhandlerContext对象。他们的主要区别是，直接写到Channel，则数据会从ChannelPipeline头部传到尾部。 每一个ChannelHandler都会处理数据，而使用ChannelHandlerContext则是将数据传送到下一个ChannelHandler。

一个 Channel 包含了一个 ChannelPipeline, 而 ChannelPipeline 中又维护了一个由 ChannelHandlerContext 组成的双向链表, 并且每个 ChannelHandlerContext 中又关联着一个 ChannelHandler。 入站事件和出站事件在一个双向链表中，入站事件会从链表head往后传递到最后一个入站的handler，出站事件会从链表tail往前传递到最前一个出站的handler，两种类型的handler互不干扰。

我们在 CustomChannelInitializer#initChannel()方法中添加编码、解码器。其中 CustomHandler 继承自SimpleChannelInboundHandler用来接收消息。

三、编解码

当你用Netty接收或发送消息，必须将其从一种格式转成另一种格式。比如收消息，你需要从字节转为Java对象。发消息就是将Java对象转成字节发出去。

Netty中有各种各样的编码器和解码器基类。

• ByteToMessageDecoder


• MessageToByteEncoder


• ProtobufEncoder


• ProtobufDecoder


• StringDecoder


• StringEncode

这里，编码器都是继承自ChannelInboundHandlerAdapter或者实现了ChannelInboundHandler。当读到数据时，会调用ChannelRead方法。重写此方法，然后就会调用decode 方法进行解码。并且会执行ChannelHandlerContext，fireChannelRead方法，将解码后的消息传给下一个Channelhandler。 当发送消息的时候，也执行类似的过程，编码器将消息转为字节，然后传给下一个ChannelOutboundHandler。

在我们的项目中，由于自定义了协议所以使用了ByteToMessageDecoder、MessageToByteEncoder。

1、编码

编码器比较简单，我们可以自定义类继承 MessageToByteEncoder 来实现解码。
需要注意的是，按照我们定义的协议顺序向 ByteBuf 中写入数据就好了。示例代码：

public class CustomEncoder extends MessageToByteEncoder<CustomMessage> {



    @Override

    protected void encode(ChannelHandlerContext channelHandlerContext, CustomMessage message, ByteBuf byteBuf) {

        //byteBuf.writeInt();

        //byteBuf.writeByte();

    }



}

2、解码

解码我们要解决TCP拆包、粘包的问题。

一般TCP中应对拆包、粘包基本有以下几种方案：

• 消息定长，这但比较好理解，由于定长了，我们可以直接判断ByteBuffer中数组长度。不过在实践过程中，一般我们不会使用这个方案，因为扩展性太差了。


• 使用特殊字符作为结尾。


• 自定义协议。

前面我们有提到我们的通信协议为[Int][String]实际上就是一个非常简易的自定义协议（由于业务简单，所以这里没有设计的非常复杂）。我们使用Int来标记后面的String长度，这样两端收到消息后，按照这个格式解析实际上就知道消息的长度了。

在Netty中，我们可以自定义类继承自 ByteToMessageDecoder，来处理解码。Netty中 ByteBuf 来处理数据。具体的步骤是：

• 先标记已读位置：byteBuf.markReaderIndex();


• 判断 ByteBuf 可读是否达到4个字节长度，如果不足直接返回，重置已读位置。


• 读取前4个字节，转为Int。


• 如果字符长度 > 0，那么接下来继续读 length 长度的字符，转为String。


• 这样整个协议就解码完成了。

这里需要注意的是：客户端要与服务端约定好是大端字节序还是小端字节序。

以上在局域网中，两款App进行TCP通信就已经搭建好了，我们有了协议上层业务就可以基于此来封装业务需要的逻辑了。实际上很多IM 通信SDK，基本上都是自定义通信协议，只是协议会比本篇中举例的协议要复杂的多。

四、优化点

项目上线一段时间后，用户反馈偶现存在两台设备无法通信的问题。后面经过调研发现是服务端进程一直存在（即Server App 并没有挂），只是TCP服务挂了。

我们在客户端有处理断线重连逻辑，但是在服务端没有做任何监控重启逻辑。

如何优化

经过调研，我们在服务端Server App中，另外启动一个客户端来与TCP服务端建立连接（相当于是我监控我自己了），如果建立失败，就重启TCP服务。

• 建立一个TCP客户端，启动轮询逻辑


• 如果该客户端没有与服务端建立连接，那么尝试建立连接。


• 如果连续三次都无法建立成功连接，那么认为此时TCP服务存在异常，重启TCP服务。


• 如果可以正常与TCP服务建立连接，那么开始向TCP服务发送心跳包


• 如果连续三次TCP服务没有回复心跳回包，那么也认为TCP服务存在异常，重启TCP服务。
  以上，就是我们针对TCP服务端的优化，上面逻辑上线后，无法建立连接的反馈就没有了。

五、总结

本篇主要是介绍如何在局域网中，两个APP使用Dns-SD协议来发现对方。自定义协议进行TCP通信，使用Netty作为TCP通信框架。

引言

最近公司整改，招了个安全测试，安全测试的同事搞了个危险的文件，悄咪咪加了个.png的后缀，就丢到我们的生产服务器上面去了，这么勇，你敢信？

不管你信不信，事实他就是发生了，就问你怕不怕。

好了，这里也就暴露了一个很大的问题，我们的开发同事判断文件类型，是使用文件后缀来判断的，所以被直接跳过。咱来看看更加科学的识别方式。

一、认识魔数

魔数：也被称为签名或文件签名，是一种用于识别文件类型和格式的短序列字节。它们通常位于文件的开头，并被设计为易于识别，以便软件可以快速确定文件是否是它所支持的格式。

魔数是一种简单的识别机制，它由一系列字节组成，这些字节在特定的文件格式中是唯一的。当一个程序打开一个文件时，它会检查文件的开始处是否包含这些特定的字节。如果找到，程序就认为文件是该格式的，并按照相应的规则进行解析和处理。

二、文件类型检测的原理

文件类型检测通常基于文件的“魔数”（magic number），也称为签名或文件签名。魔数是文件开头的字节序列，用于标识文件格式。以下是文件类型检测的原理和步骤：

2.1 文件头的读取方法

打开文件：首先，需要以二进制模式打开文件，以便能够读取文件的原始字节。

读取字节：接着，读取文件开头的一定数量的字节（通常是前几个字节）。

关闭文件：读取完成后，关闭文件以释放资源。

2.2 如何通过文件头识别文件类型

比较魔数：将读取的字节与已知的文件类型魔数进行比较。

匹配类型：如果字节序列与某个文件类型的魔数匹配，则可以确定文件类型。

处理异常：如果字节序列与任何已知魔数都不匹配，可能需要进一步的分析或返回未知文件类型。

三、Java实现文件类型检测

当需要通过文件头（魔数头）判断文件类型时，可以按照以下文字描述的流程进行实现：

graph LR

F[打开文件] --> B[读取文件头]

B --> C[判断文件类型]

C --> D[比较文件头]

D --> E[输出文件类型]



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

3.1 具体实现方法

3.1.1 定义枚举类

/**

 * 文件类型魔数枚举

 * 使用场景：用于判断文件类型

 * 使用方法：FileUtils.isFileType(new FileInputStream(file), FileTypeEnum.XLSX)

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:37

 */

public enum FileTypeEnum {

    /**

     * JPEG

     */

    JPEG("JPEG", "FFD8FF"),



    /**

     * PNG

     */

    PNG("PNG", "89504E47"),



    /**

     * GIF

     */

    GIF("GIF", "47494638"),



    /**

     * TIFF

     */

    TIFF("TIFF", "49492A00"),



    /**

     * Windows bitmap

     */

    BMP("BMP", "424D"),



    /**

     * CAD

     */

    DWG("DWG", "41433130"),



    /**

     * Adobe photoshop

     */

    PSD("PSD", "38425053"),



    /**

     * Rich Text Format

     */

    RTF("RTF", "7B5C727466"),



    /**

     * XML

     */

    XML("XML", "3C3F786D6C"),



    /**

     * HTML

     */

    HTML("HTML", "68746D6C3E"),



    /**

     * Outlook Express

     */

    DBX("DBX", "CFAD12FEC5FD746F "),



    /**

     * Outlook

     */

    PST("PST", "2142444E"),



    /**

     * doc;xls;dot;ppt;xla;ppa;pps;pot;msi;sdw;db

     */

    OLE2("OLE2", "0xD0CF11E0A1B11AE1"),



    /**

     * Microsoft Word/Excel

     */

    XLS_DOC("XLS_DOC", "D0CF11E0"),



    /**

     * Microsoft Access

     */

    MDB("MDB", "5374616E64617264204A"),



    /**

     * Word Perfect

     */

    WPB("WPB", "FF575043"),



    /**

     * Postscript

     */

    EPS_PS("EPS_PS", "252150532D41646F6265"),



    /**

     * Adobe Acrobat

     */

    PDF("PDF", "255044462D312E"),



    /**

     * Windows Password

     */

    PWL("PWL", "E3828596"),



    /**

     * ZIP Archive

     */

    ZIP("ZIP", "504B0304"),



    /**

     * ARAR Archive

     */

    RAR("RAR", "52617221"),



    /**

     * WAVE

     */

    WAV("WAV", "57415645"),



    /**

     * AVI

     */

    AVI("AVI", "41564920"),



    /**

     * Real Audio

     */

    RAM("RAM", "2E7261FD"),



    /**

     * Real Media

     */

    RM("RM", "2E524D46"),



    /**

     * Quicktime

     */

    MOV("MOV", "6D6F6F76"),



    /**

     * Windows Media

     */

    ASF("ASF", "3026B2758E66CF11"),



    /**

     * MIDI

     */

    MID("MID", "4D546864"),

    /**

     * xlsx

     */

    XLSX("XLSX", "504B0304"),

    /**

     * xls

     */

    XLS("XLS", "D0CF11E0A1B11AE1");



    private String key;

    private String value;



    FileTypeEnum(String key, String value) {

        this.key = key;

        this.value = value;

    }



    public String getValue() {

        return value;

    }



    public String getKey() {

        return key;

    }

}

3.1.2 文件类型判断工具类

import java.io.IOException;

import java.io.InputStream;



/**

 * 文件类型判断工具类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:38

 */

public class FileTypeUtils {



    /**

     * 获取文件头

     *

     * @param inputStream 输入流

     * @return 16 进制的文件投信息

     * @throws IOException io异常

     */

    private static String getFileHeader(InputStream inputStream) throws IOException {

        byte[] b = new byte[28];

        inputStream.read(b, 0, 28);

        inputStream.close();

        return bytes2hex(b);

    }



    /**

     * 将字节数组转换成16进制字符串

     *

     * @param src 文件字节数组

     * @return 16进制字符串

     */

    private static String bytes2hex(byte[] src) {

        StringBuilder stringBuilder = new StringBuilder("");

        if (src == null || src.length <= 0) {

            return null;

        }

        for (byte b : src) {

            int v = b & 0xFF;

            String hv = Integer.toHexString(v);

            if (hv.length() < 2) {

                stringBuilder.append(0);

            }

            stringBuilder.append(hv);

        }

        return stringBuilder.toString();

    }



    /**

     * 判断指定输入流是否是指定文件格式

     *

     * @param inputStream  输入流

     * @param fileTypeEnum 文件格式枚举

     * @return true 是； false 否

     * @throws IOException io异常

     */

    public static boolean isFileType(InputStream inputStream, FileTypeEnum fileTypeEnum) throws IOException {

        if (null == inputStream) {

            return false;

        }

        String fileHeader = getFileHeader(inputStream);

        return fileHeader.toUpperCase().startsWith(fileTypeEnum.getValue());

    }



}

3.1.3 测试方法

import java.io.File;

import java.io.FileInputStream;

import java.io.FileNotFoundException;

import java.io.IOException;



/**

 * 测试：判断文件是否是excel

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2024/5/23 19:33

 */

public class Test {



    public static void main(String[] args) {

        File file = new File("C:\Users\Admin\Desktop\temp\Import file.xlsx");

        try (FileInputStream fileInputStream = new FileInputStream(file)) {

            if (!FileTypeUtils.isFileType(fileInputStream, FileTypeEnum.XLSX) || !FileTypeUtils.isFileType(fileInputStream, FileTypeEnum.XLS)) {

                System.out.println(true);

            } else {

                System.out.println(false);

            }

        } catch (FileNotFoundException e) {

            e.printStackTrace();

        } catch (IOException e) {

            e.printStackTrace();

        }

    }



}

四、其它注意事项

在处理文件类型检测和数据保护时，安全性和隐私是两个非常重要的考虑因素。以下是一些相关的安全性问题和最佳实践：

4.1 魔数检测的安全性问题

graph LR

F(文件类型判断)

B(魔数检测的安全性问题)

C(误报和漏报)

D(恶意文件伪装)

E(更新和维护)



F ---> B

B ---> C

B ---> D

B ---> E



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

4.2 数据保护和隐私的最佳实践

graph LR

I(文件类型判断)



A(数据保护和隐私的最佳实践)



G(最小权限原则)

B(数据加密)

C(安全的数据传输)

D(访问控制)

E(定期审计和测试)

F(数据最小化)



I ---> A

A ---> B

A ---> C

A ---> D

A ---> E

A ---> F

A ---> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

style G fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style A fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#EEDD82,stroke:#EEDD82,stroke-width:2px

4.3 魔数的局限性和风险

魔数判断文件类型是一种常用的方法，但也存在一些局限性和风险，包括以下几点：

graph LR

I(文件类型判断)



A(魔数的局限性和风险)



B(可伪造性)

C(文件类型扩展性)

D(文件损坏或篡改)

E(多重文件类型)

F(文件类型模糊性)



I ---> A

A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#B2FFFF,stroke:#B2FFFF,stroke-width:2px

style A fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#EEDD82,stroke:#EEDD82,stroke-width:2px

五、总结

好了，到这里魔数怎么用的就说明白了。

魔数的广泛的应用在在文件类型检测中。魔数是文件开头的特定字节序列，帮助软件快速识别文件格式。

然而，魔数检测存在安全性问题，如误报、恶意伪装等，需定期更新魔数库。此外，应用魔数检测时要考虑文件损坏、多重类型等局限性，结合实际情况采取综合措施，如数据加密、访问控制等，确保安全性和准确性。

希望本文对您有所帮助。如果有任何错误或建议，请随时指正和提出。

同时，如果您觉得这篇文章有价值，请考虑点赞和收藏。这将激励我进一步改进和创作更多有用的内容。

感谢您的支持和理解！

大家好呀，我是summo，JDK版本升级的非常快，现在已经到JDK20了。JDK版本虽多，但应用最广泛的还得是JDK8，正所谓“他发任他发，我用Java8”。

其实我也不太想升级JDK版本，感觉投入高，收益小，不过有一次我看到了一些使用JDK17新语法写的代码，让我改变了对升级JDK的看法，因为这些新语法我确实想用！

废话不多说，上代码！

一、JDK17语法新特性

1. 文本块

这个更新非常实用。在没有这个特性之前，编写长文本非常痛苦。虽然IDEA等集成开发工具可以自动处理，但最终效果仍然丑陋，充满拼接符号。现在，通过字符串块，我们可以轻松编写JSON、HTML、SQL等内容，效果更清爽。这个新特性值得五颗星评价，因为它让我们只需关注字符串本身，而无需关心拼接操作。

原来的写法

/**

 * 使用JDK8返回HTML文本

 *

 * @return 返回HTML文本

 */

public static final String getHtmlJDK8() {

    return "<html>\n" +

        " <body>\n" +

        " <p>Hello, world</p>\n" +

        " </body>\n" +

        "</html>";

}

新的写法

/**

 * 使用JDK17返回HTML文本

 *

 * @return 返回HTML文本

 */

public static final String getHtmlJDK17() {

    return """

        <html>

            <body>

                <p>Hello, world</p>

            </body>

        </html>

        """;

}

推荐指数：⭐️⭐️⭐️⭐️⭐️

2. NullPointerException增强

这一功能非常强大且实用，相信每位Java开发者都期待已久。空指针异常（NPE）一直是Java程序员的痛点，因为报错信息无法直观地指出哪个对象为空，只抛出一个NullPointerException和一堆堆栈信息，定位问题耗时且麻烦。尤其在遇到喜欢级联调用的代码时，逐行排查更是令人头疼。如果在测试环境中，可能还需通过远程调试查明空对象，费时费力。为此，阿里的编码规范甚至不允许级联调用，但这并不能彻底解决问题。Java17终于在这方面取得了突破，提供了更详细的空指针异常信息，帮助开发者迅速定位问题源头。

public static void main(String[] args) {

    try {

        //简单的空指针

        String str = null;

        str.length();

    } catch (Exception e) {

        e.printStackTrace();

    }

    try {

        //复杂一点的空指针

        var arr = List.of(null);

        String str = (String)arr.get(0);

        str.length();

    } catch (Exception e) {

        e.printStackTrace();

    }

}

运行结果

推荐指数：⭐️⭐️⭐️⭐️⭐️

3. Records

在Java中，POJO对象（如DO、PO、VO、DTO等）通常包含成员变量及相应的Getter和Setter方法。尽管可以通过工具或IDE生成这些代码，但修改和维护仍然麻烦。Lombok插件为此出现，能够在编译期间自动生成Getter、Setter、hashcode、equals和构造函数等代码，使用起来方便，但对团队有依赖要求。
为此，Java引入了标准解决方案：Records。它通过简洁的语法定义数据类，大大简化了POJO类的编写，如下所示。虽然hashcode和equals方法仍需手动编写，但IDE能够自动生成。这一特性有效解决了模板代码问题，提升了代码整洁度和可维护性。

package com.summo.jdk17;



/**

 * 3星

 *

 * @param stuId     学生ID

 * @param stuName   学生名称

 * @param stuAge    学生年龄

 * @param stuGender 学生性别

 * @param stuEmail  学生邮箱

 */

public record StudentRecord(Long stuId,

                            String stuName,

                            int stuAge,

                            String stuGender,

                            String stuEmail) {

    public StudentRecord {

        System.out.println("构造函数");

    }



    public static void main(String[] args) {

        StudentRecord record = new StudentRecord(1L, "张三", 16, "男", "xxx@qq.com");

        System.out.println(record);

    }

}