【2024秋招】2023-9-20 度小满信贷系统平台部二面

2023-10-21 10:44
文章标签 系统 平台 2023 秋招 2024 20 二面 信贷 度小满

本文主要是介绍【2024秋招】2023-9-20 度小满信贷系统平台部二面，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1 面试官的部门介绍

我们部门是信贷系统平台部，主要是为度小满做一个服务，你应该也接触过信用卡，跟这种差不多，用户可以打进我们的系统申请一个额度，整个部门的规模大概是400-500人左右，我个人来自平台数据团队，主要是收敛整个信贷部门的数据，然后供给其他部门使用，比如风控团队，风控主要做的是用于判断一个人的贷款资质和额度的系统，平台部的技术团队大概40-50人，我们这儿的技术栈主要是spring，springMVC，像spring cloud也有在用，但是自研的也有，我们跟数据打交道比较多，然后还会用一些hadoop，hive等技术栈和能力，除了java，还有go，php，但是可能是其他部门；此外，即使三面都通过的话，也不一定是在我们部门，到时候可能会再做一个挑选

2 场景设计

2.1 如果你接到一个需求，这个需求涉及到访问其他的api，你能从不同的角度，安全性，可用性、高性能角度，说明一下这个接口应该具备哪些能力嘛

答：

当然可以。如果你接到一个需求，需要设计一个接口来访问其他的API，从安全性、可用性和高性能的角度，该接口应具备以下能力：

1. 安全性:

  1. 鉴权 (Authentication): 确保只有合法的用户或应用程序可以访问你的接口。常用的方法包括API密钥、OAuth、JWT等。

  2. 授权 (Authorization): 确保已经鉴权的用户或应用只能访问它们被允许的资源和操作。

  3. 数据加密: 使用HTTPS进行传输，确保数据在传输过程中不被截取或篡改。如果需要，还可以使用端到端加密。

  4. 错误处理: 避免显示敏感信息，例如数据库错误或调试信息。

  5. 防御性编程: 对输入进行验证和清理，以避免SQL注入、跨站脚本(XSS)等常见的安全威胁。

  6. 频率限制: 限制API的调用频率，防止恶意用户进行洪水攻击或过多请求。

2. 可用性:

  1. 冗余: 如果可能，确保有备份或多个服务器实例来处理请求，以避免单点故障。

  2. 负载均衡: 使用负载均衡器，确保所有的服务器实例都有均匀的流量，并在某个实例故障时自动切换。

  3. 健康检查: 定期检查API的健康状况，确保其正常运行。

  4. 优雅的降级: 当外部服务或资源不可用时，提供有意义的错误信息或回退到备用的服务。

  5. 文档: 提供详细且易于理解的API文档，方便其他开发者使用。

  6. 使用限流算法：调用别人的时候，比如运营商接口，可以在运营商一方使用漏桶算法，如果想要应对突发流量，同时保护自己，使用令牌桶算法或者滑动窗口计数器

  7. **监控：**监控的时候发现负载过高，添加新节点，

3. 高性能:

  1. 缓存: 使用缓存技术（如Redis、Memcached等）来缓存经常被查询的数据或结果，减少数据库或外部API的查询。

  2. 异步处理: 对于需要长时间处理的请求，考虑使用异步处理，然后再通知用户结果。

  3. 优化数据库查询: 确保数据库查询已经优化，避免N+1问题，使用索引等。

  4. 并发处理: 使用并发编程模型，确保API可以同时处理多个请求。

  5. 压缩: 使用gzip或其他技术压缩API响应，减少数据传输的大小和时间。

  6. 连接持久化: 使用持久化连接如HTTP/2，以减少建立和关闭连接的开销。

  7. 监控性能: 使用监控工具来跟踪API的性能，如响应时间、错误率等，以便进行及时的优化。

这只是对这个话题的一个初步概述，每个点都可以深入探讨，取决于具体的应用场景和需求。

2.2 还有没有其他需要考虑的点

当然，除了上述提到的关于安全性、可用性和高性能的建议之外，还有其他一些重要的考虑因素。以下是对一个API应具备的其他能力的扩展：

4. 扩展性：

  1. 模块化设计: 设计API时，应考虑到将来可能的变更和扩展，模块化的设计可以确保在不影响现有功能的情况下添加新功能。
  2. 版本管理: 随着业务需求的发展，API可能需要进行更改。通过合理的版本管理策略，可以确保向后兼容，同时支持新的功能。

5. 透明度与监控：

  1. 日志记录: 记录API的使用情况，包括访问者、时间、响应时间、返回的数据和任何可能的错误。
  2. 告警系统: 在出现异常或错误时，系统应能自动发送警报，以便及时处理。
  3. 可视化监控: 使用工具如Grafana、Kibana等，以图形化的方式显示API的性能和使用情况。

6. 用户友好性：

  1. 清晰的错误信息: 当用户发送的请求有问题时，返回的错误信息应该足够清晰，使用户能够理解问题并采取相应的措施。
  2. 支持多种格式: 考虑支持不同的数据格式，如JSON, XML等，以满足不同用户的需求。

7. 兼容性：

  1. 跨平台: 保证API可以在不同的操作系统和设备上使用。
  2. 跨语言: API应设计成语言无关的，以便各种编程语言都可以方便地调用。

8. 业务相关：

  1. 限流与计费: 如果API是一个付费服务，需要有一个机制来跟踪用户的使用情况，并根据使用量进行计费。
  2. 数据备份与恢复: 确保有备份策略，并且可以在数据丢失或损坏时恢复。

9. 测试：

  1. 自动化测试: 建立自动化测试，确保API的每次更改都不会引入新的错误。
  2. 压力测试: 测试API在高流量下的表现，确保其在实际生产环境中的稳定性。

以上只是对API设计和实施时应考虑的方面的一个总览。具体的需求和实践可能会有所不同，但这为你提供了一个良好的起点。

2.3 你的秒杀系统是怎么做测试的

答：使用jmeter，开启1w个线程模拟10000个用户，然后测试三轮，取得的平均值

2.4 你的系统在云服务器部署过是嘛

答：没，单机部署

2.5 一个接口A会调用接口B和C，B返回的时间是100ms，C返回的时间不固定，可能是200ms，也可能是800ms，现在要求A接口在500ms内收到B和C中任意一个接口返回结果，A就返回结果给用户。如何实现

2.5.1 方法一：使用CompletableFuture发送两个异步调用请求，然后再使用CompletableFuture的静态方法编排两个异步请求的返回结果，其中可以加一个500ms的时间戳，如果500ms内有任意一个请求返回则返回，都没有返回就抛异常

import java.util.concurrent.*;public class InterfaceCaller {private static final Executor executor = Executors.newFixedThreadPool(2);public static String callInterfaceB() {// Simulate calling Interface B// ... your implementation here ...return "Response from B";}public static String callInterfaceC() {// Simulate calling Interface C// ... your implementation here ...return "Response from C";}public static void main(String[] args) {CompletableFuture<String> futureB = CompletableFuture.supplyAsync(() -> callInterfaceB(), executor);CompletableFuture<String> futureC = CompletableFuture.supplyAsync(() -> callInterfaceC(), executor);try {String result = CompletableFuture.anyOf(futureB, futureC).get(500, TimeUnit.MILLISECONDS);System.out.println(result);} catch (TimeoutException e) {System.out.println("Timeout exceeded!");} catch (Exception e) {e.printStackTrace();}}
}

2.5.2 方法二： 以Apache Kafka为例，详细描述下发消息、消费消息再到返回消息的完整过程：

1. 消息下发:

  • 生产者创建：接口A作为消息的生产者，首先需要创建一个Kafka生产者实例。

  • 主题选择：接口A选择或创建一个主题（例如request-topic）来发布其请求消息。

  • 发布消息：接口A生成一个唯一的请求ID并发布消息到request-topic。这个消息除了包含业务数据外，还应该有其他元数据，如请求ID、时间戳等。

2. 消息消费:

  • 消费者创建：接口B和C作为消息的消费者，它们分别创建Kafka消费者实例并订阅request-topic。

  • 消息读取：接口B和C监听request-topic，当接口A的请求消息到达时，它们会从主题中拉取消息。

  • 业务逻辑处理：接口B或C读取消息内容，并开始进行必要的业务逻辑处理。

3. 消息返回:

  • 选择返回的主题：完成处理后，接口B或C选择一个返回主题（例如response-topic-interfaceB或response-topic-interfaceC）来发布其响应消息。

  • 发布响应消息：接口B或C生成响应消息，确保在其中包含原始请求的ID和处理结果，然后发布到相应的返回主题。

  • 接口A消费返回消息：接口A此时转变为消费者的角色，它订阅并监听response-topic-interfaceB和response-topic-interfaceC等待响应。为了确保在500ms内获得响应，接口A设置一个定时器。

  • 超时与响应处理：如果接口A在500ms内收到了来自接口B或C的响应，它会中止其定时器并处理返回的消息。如果超时，接口A可以返回一个错误消息或默认响应。

整个过程涉及了消息的生产、消费、业务处理和响应，是一个典型的发布-订阅模型。使用Apache Kafka，你可以利用其高吞吐量、持久性和分布式特性来实现这一过程。但同样要注意，引入消息队列会带来一定的延迟，尤其是在高并发的场景中，因此在设计时应权衡实时性和可靠性。

2.5.3 使用Kafka和使用CompletableFuture实现异步操作各有优劣。下面是两者的比较：

使用Kafka

优点：

  1. 解耦：生产者和消费者之间解耦，它们可以独立地进行扩展、部署和维护。
  2. 持久性：Kafka提供了消息持久性，即使消费者或生产者崩溃，消息仍然存在并可以被重新消费。
  3. 可靠性：Kafka设计用于处理大量消息流，具有高可靠性和容错能力。
  4. 可扩展性：Kafka集群可以水平扩展，以满足更高的吞吐量需求。
  5. 后处理能力：由于消息被存储，你可以稍后进行消费，这对于日志处理、分析等后处理任务很有用。

缺点：

  1. 延迟：Kafka的消息传递可能不如直接调用快，尤其是在高并发的情况下。
  2. 复杂性：引入Kafka会增加系统的复杂性，需要管理和维护Kafka集群。
  3. 资源开销：Kafka需要额外的资源如存储、CPU和内存。
使用CompletableFuture

优点：

  1. 简单性：使用CompletableFuture实现并发操作通常比设置和维护Kafka更简单。
  2. 速度：CompletableFuture为内存中的操作提供了近乎实时的响应速度。
  3. 直接性：直接使用Java API，无需额外的中间件或依赖。
  4. 灵活性：CompletableFuture提供了丰富的API，如组合、链式操作等，使得编写复杂的异步逻辑更为方便。

缺点：

  1. 局限性：CompletableFuture主要用于单个JVM中的并发操作，不适用于分布式系统或跨服务的通信。
  2. 非持久性：如果应用崩溃，CompletableFuture中的操作可能会丢失。
  3. 资源限制：所有并发操作共享同一个JVM的资源，如果任务太多，可能会导致资源耗尽。

总结：

  • 对于在单个应用或服务内需要快速并发处理的场景，CompletableFuture是一个很好的选择。
  • 对于需要跨应用、跨服务或分布式环境中的消息传递、解耦和持久性的场景，Kafka或其他消息队列是更合适的选择。

选择哪种方法取决于你的具体需求、资源和项目的复杂性。

3 rpc框架

3.1 你的rpc框架使用http做通信和使用rpc做通信有什么区别吗

答：

首先，我们应当明确一点：RPC（Remote Procedure Call）是一种远程过程调用模式，而HTTP（HyperText Transfer Protocol）是一种应用层协议。RPC不是一个具体的通信协议；实际上，RPC可以使用多种协议来实现，其中HTTP只是其中之一。因此，RPC和HTTP并不是直接相对的概念。

但在许多上下文中，当人们提到"使用RPC做通信"时，他们实际上是指使用某种专门为RPC设计的协议（例如gRPC、Thrift、RMI等），而不是通用的HTTP协议。基于这一点，我们可以讨论使用专为RPC设计的协议与使用HTTP协议进行RPC的区别：

  1. 效率与性能:

    • 专为RPC设计的协议（如gRPC）：通常使用了诸如Protocol Buffers这样的二进制格式，这比传统的HTTP+JSON/XML组合更为高效，因为它减少了序列化/反序列化的开销。
    • HTTP：通常使用文本格式（如JSON或XML），这可能比二进制格式慢。

  2. 通信模式:

    • 专为RPC设计的协议：支持多种通信模式，包括请求/响应、双向流、服务器推送等。
    • HTTP/1.1：主要是请求/响应模式。尽管可以使用技术如长轮询来模拟服务器推送，但这不是最佳的方法。
    • HTTP/2：支持多种模式，如双向流和服务器推送，因此与专为RPC设计的协议更为相似。

  3. 开发友好度:

    • 专为RPC设计的协议：通常需要更多的开发工具和库，如IDL（接口定义语言）工具，用于生成客户端和服务器代码。
    • HTTP：更为普遍且通用，开发者可能已经熟悉它。但为HTTP创建RPC风格的API可能需要更多的手工编码。

  4. 互操作性和生态系统:

    • 专为RPC设计的协议：可能需要特定的库和工具，这可能限制了其与其他系统的互操作性。
    • HTTP：由于其普遍性，它具有广泛的互操作性和强大的生态系统。

  5. 安全性:

    • 两者都支持加密和认证机制，但具体的实现和工具可能会有所不同。

  6. 传输协议:

    • 专为RPC设计的协议：虽然许多都是基于TCP的，但它们可能会使用特定的传输协议，如gRPC使用HTTP/2。
    • HTTP：可以运行在多种传输协议上，但通常是TCP。

总的来说，选择使用专为RPC设计的协议还是HTTP进行RPC主要取决于应用的具体需求，例如性能、开发经验、互操作性等因素。

3.2 说一下你这个自定义协议的结构

答：

3.3 你用的是哪种序列化协议，为什么不考虑kryo，json这种序列化协议呢

答：我和json做了一下对比

我基于OpenAI的设计决策，并不直接决定使用哪种序列化协议。但我可以为你解释为什么在某些应用中，人们可能选择Protocol Buffers而不是Kryo、JSON等其他序列化格式。

  1. 性能和效率:

    • Protocol Buffers (ProtoBuf): 是一个二进制格式，非常高效，尤其在序列化和反序列化时。由于其紧凑的特性，ProtoBuf在网络传输和存储时也十分高效。
    • Kryo: 是一个高效的Java序列化库，也是二进制的，通常比Java的默认序列化更快。但Kryo主要针对Java，而ProtoBuf是跨平台和跨语言的。
    • JSON: 是文本格式，通常比二进制格式大并且序列化/反序列化速度相对较慢。但其可读性好并且被广泛支持，非常适合Web API和配置。

  2. 跨语言支持:

    • ProtoBuf: 支持多种语言，如Java、C++、Python、Go等。这使得在不同的系统和语言之间进行通信变得简单。
    • Kryo: 主要为Java设计。如果你的系统完全基于Java，Kryo可能是一个很好的选择，但它不如ProtoBuf那么灵活。
    • JSON: 几乎所有编程语言都支持，非常通用。

  3. 模式的演进:

    • ProtoBuf: 允许你在不破坏向后兼容性的情况下修改数据结构。这在分布式系统中，特别是在需要进行持续部署的环境中，是非常有价值的。
    • Kryo & JSON: 对模式的变更可能不那么友好，尤其是在大型、快速变化的系统中。

  4. 可读性与调试:

    • ProtoBuf: 由于是二进制格式，不如文本格式易于阅读和调试。
    • Kryo: 也是二进制格式，具有与ProtoBuf相同的限制。
    • JSON: 易于阅读和调试，因为它是文本格式。

  5. 生态系统和工具支持:

    • ProtoBuf: 有一个成熟的生态系统，包括代码生成、文档工具等。
    • Kryo: 为Java生态系统提供了良好的支持，但不像ProtoBuf那样广泛。
    • JSON: 有大量的库和工具可供选择。

总之，选择哪种序列化协议取决于具体的需求。ProtoBuf在许多高性能、大规模和跨语言的应用中是首选，但在特定的上下文中，Kryo或JSON可能更为合适。

4 tomcat

4.1 tomcat和netty的区别

答：

Tomcat：

  • 类型: Tomcat是一个Java Servlet容器和Web服务器。它能够执行Java Servlet和呈现JSP页面。
  • 使用: 主要用于部署和运行Java EE应用。
  • 性能: 尽管Tomcat进行了优化，但它可能不如专门设计的非阻塞框架如Netty那样高性能。
  • 模型: Tomcat使用多线程模型来处理并发请求，通常为每个请求创建一个线程。

Netty：

  • 类型: Netty是一个高性能、异步的、基于事件驱动的网络应用框架。它支持多种协议。
  • 使用: 主要用于开发高性能、高可靠性的网络应用，如RPC框架。
  • 性能: Netty是为高并发、高性能设计的，使用了非阻塞I/O。
  • 模型: Netty使用事件驱动模型，可以轻松处理成千上万的并发连接。

4.2 tomcat打破双亲委派模型的目的是什么

答：

双亲委派模型的主要目的是为了保证Java核心库的类型安全性。但是，在Web容器环境中，如果遵循传统的双亲委派模型，可能会遇到一些问题。例如，如果两个Web应用部署在同一个容器中并且它们使用了不同版本的同一个库，传统的委派模型可能会导致其中一个应用获取到错误的库版本。为了解决这个问题并为Web应用提供更大的灵活性，Tomcat选择打破了传统的双亲委派模型。

4.3 tomcat如何打破双亲委派的

Tomcat引入了一个叫做Web Application Classloader的特殊类加载器。按照传统的双亲委派模型，类加载器首先会委托给其父加载器来加载类；只有当父加载器无法加载该类时，类加载器才尝试自己加载该类。

但在Tomcat中，Web Application Classloader会首先尝试加载Web应用下的类，如果没有找到，它才会委派给其父加载器。这样，Web应用就可以自由地使用自己的库版本，而不受共享库的影响。

这种做法确实打破了传统的双亲委派模型，但它为Web应用提供了更大的灵活性，并解决了多个应用在同一个容器中共存时可能遇到的库冲突问题。

5 故障排查

5.1 如何完成故障排查的，举个例子

答：

5.2 有没有使用arthas排查出性能问题，然后做出优化

答：

5.3 如果你负责的项目，经常发生ygc，是什么原因

答：

我的答案：

（1）内存泄露，资源没有回收

（2）应用不断new出新的对象

（3）minorGC时的并发线程数设置的过低，回收速度赶不上

gpt4答案：

经常发生Young GC（YGC）可能是由多种原因导致的。以下是一些常见的原因及其描述：

  1. 短生命周期的对象产生过多：

    • 如果应用创建了大量的短生命周期的对象（即对象很快被创建然后变得不可达），这些对象会迅速填满年轻代（Young Generation）并触发YGC。

  2. 年轻代空间设置不当：

    • 如果年轻代的大小设置得太小，YGC可能会频繁发生。你可以考虑调整年轻代的大小来适应应用的需求。

  3. 代码存在不良的数据结构或算法：

    • 例如，使用了产生大量临时对象的循环或算法。

  4. 外部因素：

    • 如频繁的文件I/O操作、数据库查询等，可能间接导致大量的临时对象创建。

  5. 使用了不适合的框架或库：

    • 某些框架或库可能在内部创建了大量的临时对象。

  6. 频繁的字符串操作：

    • 如大量的字符串拼接操作可能会产生大量的临时字符串对象。

  7. 频繁使用了缓存：

    • 如果缓存策略或大小设置不当，可能会导致大量的对象进入年轻代。

  8. 应用负载突然增大：

    • 如应用突然接收到大量请求，可能会短时间内产生大量的临时对象。

要诊断和解决频繁的YGC，你可以采取以下措施：

  • 使用JVM监控工具，如jstat、VisualVM或Java Mission Control，来查看GC的频率、持续时间和内存使用情况。

  • 使用Java的堆分析工具，如HeapDump或jmap，来查看哪些对象占用了最多的年轻代空间。

  • 根据上述工具的输出，调整年轻代大小或优化代码来减少短生命周期的对象的产生。

  • 在优化后，持续监控以确保问题得到了解决。

5.4 YGC的根引在哪儿

答：方法区，栈帧中的局部变量表中，也存在引用，同时还有常量池

5.5 针对不断new出的对象，如何解决

答：单例

针对不断被new出来的对象，以下是一些解决方案和建议：

  1. 对象池化:

    • 对于经常创建和短时间内就被销毁的对象，你可以使用对象池。例如，Apache Commons Pool 提供了一种通用的对象池化解决方案。通过重用对象，你可以减少需要频繁创建和销毁的对象的数量，从而减少GC的压力。

  2. 减少临时对象的创建:

    • 优化代码，避免创建不必要的临时对象。例如，对于字符串操作，可以考虑使用StringBuilder或StringBuffer来减少临时字符串的创建。

  3. 优化数据结构和算法:

    • 审查代码中使用的数据结构和算法，确保它们不会产生大量的临时对象。

  4. 缓存:

    • 对于经常被创建但状态不经常改变的对象，可以考虑使用缓存来存储这些对象，而不是每次都重新创建。

  5. 延迟对象的创建:

    • 只有在真正需要对象时才创建它，而不是预先创建。

  6. 调整JVM参数:

    • 调整Young Generation的大小，这可能会影响YGC的频率和持续时间。

  7. 使用单例：单例能够节约空间，避免对象的重复创建

这篇关于【2024秋招】2023-9-20 度小满信贷系统平台部二面的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/253870。

相关文章

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

流媒体平台/视频监控/安防视频汇聚EasyCVR播放暂停后视频画面黑屏是什么原因？

视频智能分析/视频监控/安防监控综合管理系统EasyCVR视频汇聚融合平台，是TSINGSEE青犀视频垂直深耕音视频流媒体技术、AI智能技术领域的杰出成果。该平台以其强大的视频处理、汇聚与融合能力，在构建全栈视频监控系统中展现出了独特的优势。视频监控管理系统EasyCVR平台内置了强大的视频解码、转码、压缩等技术，能够处理多种视频流格式，并以多种格式（RTMP、RTSP、HTTP-FLV、WebS
阅读更多...
不懂推荐算法也能设计推荐系统

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例，告诉我们不懂推荐算法的产品，也能从产品侧出发， 设计出一款不错的推荐系统。 相信很多新手产品，看到算法二字，多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法（注：传统是指科班出身的产品都会接触过）。但对于推荐算法，多数产品对着网上搜到的资源，都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后，更是加大了理解的难度。 但，不了解推荐算法，就无法做推荐系
阅读更多...
基于人工智能的图像分类系统

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务，目标是自动识别图像中的对象类别。通过卷积神经网络（CNN）等深度学习技术，我们可以构建高效的图像分类系统，广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统，包括环境
阅读更多...
水位雨量在线监测系统概述及应用介绍

水位雨量在线监测系统概述及应用介绍

在当今社会，随着科技的飞速发展，各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中，水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术，其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成，形成了一个完整的闭环系统。 数据采集单元：这是系统的“眼睛”，
阅读更多...
综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

综合安防管理平台LntonAIServer视频监控汇聚抖动检测算法优势

LntonAIServer视频质量诊断功能中的抖动检测是一个专门针对视频稳定性进行分析的功能。抖动通常是指视频帧之间的不必要运动，这种运动可能是由于摄像机的移动、传输中的错误或编解码问题导致的。抖动检测对于确保视频内容的平滑性和观看体验至关重要。 优势 1. 提高图像质量 - 清晰度提升：减少抖动，提高图像的清晰度和细节表现力，使得监控画面更加真实可信。 - 细节增强：在低光条件下，抖
阅读更多...
2024年流动式起重机司机证模拟考试题库及流动式起重机司机理论考试试题

2024年流动式起重机司机证模拟考试题库及流动式起重机司机理论考试试题

题库来源：安全生产模拟考试一点通公众号小程序 2024年流动式起重机司机证模拟考试题库及流动式起重机司机理论考试试题是由安全生产模拟考试一点通提供，流动式起重机司机证模拟考试题库是根据流动式起重机司机最新版教材，流动式起重机司机大纲整理而成（含2024年流动式起重机司机证模拟考试题库及流动式起重机司机理论考试试题参考答案和部分工种参考解析），掌握本资料和学校方法，考试容易。流动式起重机司机考试技
阅读更多...
嵌入式QT开发：构建高效智能的嵌入式系统

嵌入式QT开发：构建高效智能的嵌入式系统

摘要： 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发，详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程，包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发，涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用，以及嵌入式 QT 与硬件设备的交互，包括输入输出设
阅读更多...
JAVA智听未来一站式有声阅读平台听书系统小程序源码

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来，一站式有声阅读平台听书系统 🌟&nbsp;开篇：遇见未来，从“智听”开始 在这个快节奏的时代，你是否渴望在忙碌的间隙，找到一片属于自己的宁静角落？是否梦想着能随时随地，沉浸在知识的海洋，或是故事的奇幻世界里？今天，就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统，它正悄悄改变着我们的阅读方式，让未来触手可及！ 📚&nbsp;第一站：海量资源，应有尽有 走进“智听
阅读更多...
【专题】2024飞行汽车技术全景报告合集PDF分享（附原数据表）

【专题】2024飞行汽车技术全景报告合集PDF分享（附原数据表）

原文链接： https://tecdat.cn/?p=37628 6月16日，小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞，这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示，公司准备量产，并计划今年四季度开启预售小鹏汇天分体式飞行汽车，探索分体式飞行汽车城际通勤。阅读原文，获取专题报告合集全文，解锁文末271份飞行汽车相关行业研究报告。 据悉，业内人士对飞行汽车行业
阅读更多...
高效录音转文字：2024年四大工具精选！

高效录音转文字：2024年四大工具精选！

在快节奏的工作生活中，能够快速将录音转换成文字是一项非常实用的能力。特别是在需要记录会议纪要、讲座内容或者是采访素材的时候，一款优秀的在线录音转文字工具能派上大用场。以下推荐几个好用的录音转文字工具！ 365在线转文字 直达链接：https://www.pdf365.cn/ 365在线转文字是一款提供在线录音转文字服务的工具，它以其高效、便捷的特点受到用户的青睐。用户无需下载安装任何软件，只
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2