Kafka——Java消费者是如何管理TCP连接的？

引言

在分布式消息系统中，网络连接是数据流转的"血管"，其管理效率直接决定了系统的吞吐量、延迟与稳定性。作为Kafka生态中负责数据消费的核心组件，Java消费者（KafkaConsumer）的TCP连接管理机制一直是开发者理解的难点。与生产者相比，消费者的连接管理更复杂——它需要与协调者（Coordinator）交互以完成组管理，还需要与多个Broker建立连接以拉取消息，这使得连接的创建、复用与关闭充满了细节陷阱。

想象这样一个场景：某电商平台的实时数据消费系统突然出现消息延迟，监控显示Kafka消费者与Broker的TCP连接数异常飙升至数千，远超预期。进一步排查发现，大量连接处于TIME_WAIT状态，导致服务器文件描述符耗尽。这个问题的根源，正是对消费者TCP连接管理机制的理解不足。

本文将从连接创建的时机、数量计算、关闭机制到优化实践，全方位解析Kafka Java消费者的TCP连接管理逻辑，从底层理解连接行为，去规避生产环境中的常见问题。

TCP连接的创建：时机与触发机制

KafkaConsumer的TCP连接创建机制与生产者存在显著差异。理解这些差异是掌握连接管理的第一步。

连接创建的触发点：从构造函数到poll方法

与KafkaProducer不同，消费者的TCP连接并非在实例化时创建。当你执行new KafkaConsumer(properties)时，只会初始化配置与内部状态，不会建立任何网络连接。这种设计避免了生产者在构造函数中启动线程导致的this指针逃逸问题，被认为是更优的实现。

连接的真正创建发生在第一次调用poll()方法时。这是一个关键的设计选择——消费者将连接创建延迟到实际需要数据时，减少了初始化阶段的资源消耗。在poll()方法内部，存在三个明确的连接创建时机：

时机1：发起FindCoordinator请求时

消费者组的正常运作依赖于协调者（Coordinator）——一个驻留在Broker端的组件，负责组成员管理、位移提交等核心功能。当消费者首次调用poll()时，它对集群一无所知，必须先发送FindCoordinator请求以定位所属的协调者。

此时，消费者会随机选择一个Broker（理论上是负载最小的，通过待发送请求数评估）建立第一个TCP连接。由于此时缺乏集群元数据，连接的Broker节点ID被标记为-1，表示这是一个临时连接。这个连接不仅用于发送FindCoordinator请求，还会被复用发送元数据请求，以获取整个集群的Broker信息。

示例日志解析：

[DEBUG] Initiating connection to node localhost:9092 (id: -1)
[TRACE] Sending FIND_COORDINATOR {key=test, key_type=0} to node -1

日志中id: -1表明这是消费者创建的第一个临时连接，用于初始的协调者发现。

时机2：连接协调者时

FindCoordinator请求的响应会返回协调者所在的Broker地址（如node_id=2）。消费者此时会立即建立第二个TCP连接，专门用于与协调者通信，执行组注册、心跳发送、位移提交等组管理操作。

为了区分组管理请求与数据请求，Kafka使用特殊的节点ID标记协调者连接：Integer.MAX_VALUE - 协调者真实ID。例如，若协调者Broker的ID为2，则连接的节点ID被标记为2147483645（2147483647-2）。这种设计确保了组管理流量与数据流量使用独立的连接，避免相互干扰。

示例日志解析：

[DEBUG] Initiating connection to node localhost:9094 (id: 2147483645)

这里的2147483645明确标识了这是与协调者的连接。

时机3：消费数据时

在确定协调者并完成组注册后，消费者会获取到分配给自己的分区。为了拉取这些分区的消息，消费者需要与每个分区的领导者副本所在的Broker建立TCP连接。这些连接的节点ID使用Broker的真实ID（如0、1、2），对应server.properties中配置的broker.id。

例如，若消费者被分配5个分区，且这些分区的领导者分布在3个Broker上，则会创建3个数据连接。这种"分区-领导者-Broker"的映射关系，直接决定了数据连接的数量。

示例日志解析：

[DEBUG] Initiating connection to node localhost:9092 (id: 0)
[DEBUG] Initiating connection to node localhost:9093 (id: 1)
[DEBUG] Initiating connection to node localhost:9094 (id: 2)

这三条日志表明消费者与ID为0、1、2的Broker建立了数据连接。

连接创建的完整流程示例

为了更清晰地理解连接创建的时序，我们通过一个具体案例展示整个过程：

  1. 初始状态：消费者实例化后，无任何TCP连接。

  2. 第一次poll()调用：

    • 步骤1：创建临时连接（ID=-1），发送FindCoordinator请求与元数据请求。

    • 步骤2：收到响应，得知协调者在Broker 2（localhost:9094），创建协调者连接（ID=2147483645）。

    • 步骤3：获取分配的分区，发现其领导者分布在Broker 0、1、2上，创建三个数据连接（ID=0、1、2）。

  3. 连接状态：此时共创建5个连接？不——实际上，临时连接（ID=-1）在数据连接建立后会被废弃，最终保留协调者连接与3个数据连接，共4个连接。

TCP连接的数量：计算与影响因素

消费者创建的TCP连接数量并非固定值，它取决于集群拓扑、分区分布与消费阶段。理解连接数量的计算逻辑，是优化网络资源占用的基础。

连接的三类划分

根据功能，消费者的TCP连接可分为三类，每类连接的数量与生命周期各不相同：

连接类型用途典型数量生命周期特点
临时连接发现协调者、获取元数据1个短期存在，数据连接建立后关闭
协调者连接组管理（注册、心跳、位移提交）1个长期存在，随消费者生命周期
数据连接拉取分区消息（与领导者副本所在Broker）取决于Broker数量长期存在，与分区分布绑定

示例：若一个消费者订阅的主题分区分布在3个Broker上，则数据连接数为3，加上1个协调者连接，共4个长期连接。

连接数量的动态变化

连接数量会随消费过程动态调整，主要体现在：

  1. 临时连接的消亡：如前所述，用于FindCoordinator的临时连接在数据连接建立后会被关闭，这是连接数量的第一次减少。

  2. Rebalance后的调整：当消费者组发生Rebalance时，分区分配可能变化，导致数据连接的增减。例如，若Rebalance后消费者不再负责某个Broker上的分区，对应的连接会被关闭（若闲置时间超过connection.max.idle.ms）。

  3. Broker故障的影响：若某个Broker宕机，其负责的分区会发生领导者选举，消费者会与新的领导者所在Broker建立连接，原连接被废弃。

连接数量计算案例

通过具体场景理解连接数量的计算，能帮助开发者快速评估实际环境中的连接规模。

案例1：2个Broker，5个分区

假设Kafka集群有2个Broker（ID=0、1），某主题有5个分区，其领导者分布如下：

  • Broker 0：分区0、1、2

  • Broker 1：分区3、4

消费者启动后，连接数量变化如下：

  1. 临时连接（ID=-1）：1个（用于发现协调者）。

  2. 协调者连接（ID=2147483647 - 协调者ID）：1个（假设协调者在Broker 0，ID=2147483646）。

  3. 数据连接：2个（分别连接Broker 0和1，因所有分区领导者仅分布在这两个Broker）。

  4. 最终连接：协调者连接（1）+ 数据连接（2）= 3个长期连接（临时连接已关闭）。

案例2：3个Broker，10个分区

若分区领导者均匀分布在3个Broker上，则数据连接数为3，加上1个协调者连接，共4个长期连接。

节点ID的特殊含义

Kafka通过节点ID的特殊值来区分连接类型，这在日志分析中至关重要：

  • ID=-1：临时连接，用于初始的FindCoordinator请求，此时消费者对集群一无所知。

  • ID=2147483645（或类似大值）：协调者连接，通过Integer.MAX_VALUE - 协调者真实ID计算得出，用于组管理操作。

  • ID=0、1、2等：数据连接，对应Broker的真实broker.id，用于拉取消息。

日志分析技巧：通过节点ID可快速定位连接用途，例如在日志中发现id: -1的连接，可判断为消费者启动初期的临时连接；id: 2147483645则对应协调者交互。

TCP连接的关闭：时机与策略

连接的关闭机制与创建同样重要。不合理的关闭策略可能导致连接泄露（僵尸连接），消耗系统资源；而过于频繁的关闭则会增加重连开销，影响性能。

主动关闭：显式与强制终止

消费者提供两种主动关闭连接的方式：

  1. 调用close()方法：这是推荐的方式。KafkaConsumer.close()会优雅关闭所有TCP连接，释放资源，并确保最终的位移提交（若配置了enable.auto.commit）。

  2. 强制终止进程：通过kill -2（触发SIGINT）或kill -9（强制终止）关闭消费者。前者会触发close()方法的调用，后者则直接终止进程，连接由操作系统回收（可能导致TIME_WAIT状态）。

自动关闭：connection.max.idle.ms的作用

Kafka消费者通过connection.max.idle.ms参数控制闲置连接的自动关闭，默认值为9分钟（540000毫秒）。若一个连接在9分钟内无任何请求活动，会被自动关闭。

这个参数的设计目的是：

  • 避免僵尸连接长期占用资源（如文件描述符）。

  • 平衡连接复用与资源释放，9分钟的默认值兼顾了大多数场景的长连接需求。

注意：由于消费者会循环调用poll()方法，协调者连接（发送心跳）与数据连接（拉取消息）通常会保持活跃，因此自动关闭机制主要作用于临时连接或Rebalance后不再使用的连接。

长连接的保持机制

消费者通过定期发送请求维持连接的活跃性：

  • 协调者连接：每隔heartbeat.interval.ms（默认3秒）发送心跳请求。

  • 数据连接：根据poll()的调用频率发送拉取请求（通常设置为秒级间隔）。

这种设计使得连接长期处于活跃状态，避免被connection.max.idle.ms判定为闲置，从而实现了"长连接"的效果，减少频繁重连的开销。

连接管理的设计局限与优化建议

尽管Kafka的连接管理机制经过多年迭代，但仍存在设计局限，可能引发生产环境问题。理解这些局限并采取针对性优化，是保障系统稳定性的关键。

临时连接的复用难题

如前所述，用于FindCoordinator的临时连接（ID=-1）无法被后续操作复用，即使它连接的Broker与数据连接的Broker相同。这是因为Kafka仅通过节点ID标识连接，而临时连接的ID=-1无法与后续的真实Broker ID关联。

影响：额外的连接创建与关闭操作，增加了初始化阶段的网络开销。在分区数众多的场景下，可能导致短暂的连接风暴。

优化建议：社区曾提议通过<主机名、端口、ID>三元组标识连接以实现复用，但目前尚未实现。生产环境中可通过减少不必要的消费者重启（避免重复创建临时连接）缓解此问题。

连接数过多的问题与解决

在大规模集群（如100+ Broker）中，消费者可能创建大量数据连接，导致：

  • 客户端：内存占用增加，文件描述符耗尽（每个连接对应一个文件描述符）。

  • 服务端：Broker的max.connections（默认无限制，但受系统资源约束）可能被触发，拒绝新连接。

解决策略：

  1. 合理规划分区分布：避免分区过度分散在多个Broker上，通过partition.assignment.strategy优化分配。

  2. 调整connection.max.idle.ms：适当减小该值（如5分钟），加速闲置连接的回收。

  3. 监控与告警：通过kafka.consumer:type=consumer-fetch-manager-metrics,client-id=*指标中的connection-count监控连接数，超过阈值时告警。

  4. 限制消费者数量：避免单个应用启动过多消费者实例，优先通过多线程方案（如方案1）提升消费能力。

连接泄露的排查与处理

连接泄露表现为TCP连接数持续增长，最终导致资源耗尽。排查步骤：

  1. 日志分析：搜索Initiating connection to node关键字，统计连接创建频率与数量，定位异常增长的连接类型（协调者连接/数据连接）。

  2. 网络监控：使用netstat或ss命令查看连接状态：

    netstat -an | grep 9092 | grep ESTABLISHED | wc -l

  3. 代码审查：检查是否存在未调用close()的消费者实例（如异常退出未执行关闭逻辑）。

处理方案：

  • 确保消费者实例在finally块中调用close()：

    KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props);
try {// 消费逻辑
} finally {consumer.close(); // 确保关闭
}

  • 升级Kafka客户端版本：某些旧版本存在连接泄露的bug（如0.10.x中的特定场景），升级到2.0+可修复。

生产环境的连接管理实践

结合理论与实践，以下是生产环境中连接管理的最佳实践，帮助平衡性能与可靠性。

关键参数调优

参数作用推荐配置
connection.max.idle.ms闲置连接自动关闭时间5分钟（300000ms），避免过长
max.poll.records单次poll()拉取的最大记录数根据处理能力调整，避免过大导致poll间隔过长
heartbeat.interval.ms心跳发送间隔3秒（默认），确保协调者连接活跃
session.timeout.ms会话超时时间10秒（默认），需小于max.poll.interval.ms

调优原则：通过压测确定max.poll.records与connection.max.idle.ms的最佳组合，确保连接既不过度闲置，也不频繁重建。

日志分析实战

通过分析Kafka消费者的DEBUG级日志，可精准定位连接问题。以下是典型日志片段的解读：

# 临时连接创建（发现协调者）
[DEBUG] Initiating connection to node localhost:9092 (id: -1)
# 复用临时连接发送元数据请求
[DEBUG] Sending metadata request to node -1
# 协调者连接创建
[DEBUG] Initiating connection to node localhost:9094 (id: 2147483645)
# 数据连接创建
[DEBUG] Initiating connection to node localhost:9092 (id: 0)

异常日志示例：

[WARN] Connection to node 0 (localhost/127.0.0.1:9092) could not be established. Broker may not be available.

此日志表明数据连接创建失败，可能原因：Broker宕机、网络分区、端口未开放等，需检查Broker状态与网络连通性。

监控指标与告警

通过JMX或Prometheus监控以下关键指标，及时发现连接异常：

  1. connection-count：当前活跃连接数，突增可能预示异常。

  2. connection-creation-rate：连接创建速率，过高可能表明连接频繁关闭重连。

  3. connection-close-rate：连接关闭速率，与创建速率不匹配需警惕。

告警阈值建议：

  • 连接数：超过Broker数量的2倍（正常情况下数据连接数≤Broker数）。

  • 连接创建速率：5分钟内增长超过100次/秒。

案例：连接风暴的解决

问题描述：某金融系统的Kafka消费者在启动后，短时间内创建了数百个TCP连接，导致Broker的netstat显示大量TIME_WAIT状态，最终触发too many open files错误。

排查过程：

  1. 日志分析发现大量Initiating connection to node (id: -1)日志，表明临时连接频繁创建。

  2. 检查代码发现，消费者被设计为每处理1000条消息重启一次，导致重复执行FindCoordinator流程。

  3. connection.max.idle.ms被设置为30分钟，远超实际需求，导致关闭延迟。

解决方案：

  1. 重构代码，避免不必要的消费者重启，通过多线程方案提升处理能力。

  2. 将connection.max.idle.ms调整为5分钟，加速闲置连接回收。

  3. 监控消费者重启频率，设置告警阈值。

效果：连接数从数百降至稳定的10个以内，TIME_WAIT状态消失，系统恢复正常。

总结

Kafka Java消费者的TCP连接管理是一个融合设计理念、网络协议与工程实践的复杂话题。掌握以下核心要点，能帮助开发者构建高效、可靠的消费系统：

  1. 连接创建的时机：poll()方法中的三个阶段（发现协调者、连接协调者、拉取数据），临时连接与长期连接的区分。

  2. 连接数量的计算：协调者连接（1个）+ 数据连接（等于分区领导者所在的Broker数），临时连接会自动关闭。

  3. 连接关闭的策略：主动关闭（close()）与自动关闭（connection.max.idle.ms）的配合，避免僵尸连接。

  4. 监控与调优：通过日志分析、指标监控及时发现连接异常，合理配置参数以平衡性能与资源消耗。

在分布式系统中，网络连接是最脆弱的环节之一。深入理解Kafka消费者的连接管理机制，不仅能解决当下的问题，更能为设计高可用、高吞吐的消费系统奠定基础。

常见问题与解答

Q1：消费者与生产者的连接管理有何核心差异？

A1：生产者在实例化时创建连接（因启动Sender线程），消费者则延迟到poll()时创建；生产者的连接数通常较少（与元数据Broker和分区领导者），消费者因组管理多一个协调者连接。

Q2：connection.max.idle.ms设置得过小会有什么影响？

A2：可能导致活跃连接被频繁关闭，增加重连开销，表现为消费延迟增加、吞吐量下降。

Q3：Rebalance会导致连接数变化吗？

A3：会。Rebalance可能改变分区分配，导致数据连接的增减，若原连接闲置超过connection.max.idle.ms会被关闭。

Q4：消费者关闭后，Broker端的连接何时释放？

A4：消费者主动关闭时，会发送LeaveGroup请求，Broker立即释放连接；强制终止时，Broker会在session.timeout.ms（默认10秒）后判定消费者死亡，释放连接。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.pswp.cn/pingmian/90582.shtml
繁体地址，请注明出处：http://hk.pswp.cn/pingmian/90582.shtml

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

idea监控本地堆栈

idea监控本地堆栈

idea 安装插件 VisualVM Launcher重启idea后&#xff0c;配置 VisualVM 属性选择自己jdk的 jvisualvm启动时&#xff0c;选择监控&#xff0c;会自动弹出 VisualVM
阅读更多...
系统性提升大模型回复准确率：从 RAG 到多层 Chunk 策略

系统性提升大模型回复准确率：从 RAG 到多层 Chunk 策略

大语言模型&#xff08;LLM&#xff09;在问答、搜索、对话等任务中展现出强大的生成能力&#xff0c;但它并不具备真实世界知识的完全记忆与对齐能力&#xff0c;尤其在涉及复杂信息、长文档引用或领域细节时&#xff0c;其“幻觉”问题&#xff08;hallucination&#xff09;…
阅读更多...
【神经网络概述】从感知机到深度神经网络（CNN RNN）

【神经网络概述】从感知机到深度神经网络（CNN RNN）

文章目录1. 神经网络基础1.1 感知器&#xff08;Perceptron)1.2 深度神经网络&#xff08;DNN&#xff09;2. 卷积神经网络&#xff08;CNN&#xff09;2.1 核心思想2.2 典型结构2.3 ⾥程碑模型:2.4 卷积层 - CNN 核心2.5 池化层3. 循环神经网络&#xff08;RNN&#xff09;3.1…
阅读更多...
界面规范3-列表下

界面规范3-列表下

4、内容文字有链接的采用蓝色字体<font colorblue></font>重要内容采用红字字体&#xff0c;如状态<font colorred></font>一般字体使用color: #3232325、行高height: 40px;line-height: 40px;6、其他表格占满界面空间&#xff0c;内容多时&#xff0c…
阅读更多...
中文语音识别与偏误检测系统开发

中文语音识别与偏误检测系统开发

中文语音识别与偏误检测系统开发 前些天发现了一个巨牛的人工智能学习网站&#xff0c;通俗易懂&#xff0c;风趣幽默&#xff0c;忍不住分享一下给大家&#xff0c;觉得好请收藏。点击跳转到网站。 1. 系统概述 本系统旨在开发一个基于Paraformer模型的中文语音识别与偏误检…
阅读更多...
MySQL创建普通用户并为其分配相关权限的操作步骤

MySQL创建普通用户并为其分配相关权限的操作步骤

1. 登录MySQL服务器 首先&#xff0c;你需要以管理员身份登录MySQL服务器。可以使用以下命令&#xff1a; mysql -u root -p 输入密码后&#xff0c;即可进入MySQL命令行界面。 2. 创建新用户 使用CREATE USER语句创建新用户。语法如下&#xff1a; CREATE USER usernamehost I…
阅读更多...
OSPF 路由协议多区域

OSPF 路由协议多区域

一、课程目标本课程旨在帮助学习者掌握 OSPF 多区域的核心知识&#xff0c;具体包括&#xff1a;掌握 OSPF 各种 LSA 的内容和传递过程、了解普通区域与特殊区域的特点、掌握 OSPF 多区域的配置。二、OSPF 多区域划分的必要性单区域存在的问题单区域 OSPF 网络中&#xff0c;存…
阅读更多...
小程序的客服咨询（与企业微信建立沟通）

小程序的客服咨询（与企业微信建立沟通）

背景&#xff1a;小程序是面向群众的。需要提供与企业的聊天窗口。 一、连接方式。 使用组件的方式最佳wx.openCustomerServiceChat 二、接入小程序 链接
阅读更多...
解码3D格式转换

解码3D格式转换

三维图形与可视化领域&#xff0c;3D模型格式作为数据交换与存储的基石&#xff0c;承载着模型结构、几何形状、纹理以及材质等多重信息。不同的3D模型格式在支持材质的方式上各有差异&#xff0c;这些差异不仅影响模型的外观表现&#xff0c;还在格式转换过程中带来了特定的挑…
阅读更多...
HarmonyOS学习记录5

HarmonyOS学习记录5

HarmonyOS学习记录5 本文为个人学习记录&#xff0c;仅供参考&#xff0c;如有错误请指出。本文主要记录网络请求的开发知识。 参考文档&#xff1a;HTTP和RCP访问网络 网络连接 概述 网络连接管理提供管理网络一些基础能力&#xff0c;包括WiFi/蜂窝/Ethernet等多网络连接优…
阅读更多...
【C/C++】explicit_bzero

【C/C++】explicit_bzero

explicit_bzero explicit_bzero 是一个为了解决 memset 在安全清除内存场景中可能被优化器移除的问题而设计的函数&#xff0c;广泛用于安全编程中&#xff0c;比如密码、密钥清除等。Introduce 头文件 #include <string.h>函数原型 void explicit_bzero(void *s, size_t…
阅读更多...
MySQL 链接方法思考

MySQL 链接方法思考

代码： import subprocess import os from dotenv import load_dotenv import pymysql from sqlalchemy import create_enginedef check_mysql_service():"""检查 MySQL 服务是否运行"""try:result = subprocess.run(["systemctl", &…
阅读更多...
jxORM--查询数据

jxORM--查询数据

jxORM提供了丰富的数据查询功能。在jxORM中&#xff0c;有两种数据查询方式&#xff1a; 通过数据类执行查询直接使用SQL的select语句查询 数据类查询 数据类查询的优势&#xff1a; 可以根据数据类的定义&#xff0c;自动完成查询条件中的条件值和查询到的数据的类型转换直接获…
阅读更多...
详解力扣高频SQL50题之1084. 销售分析 III【简单】

详解力扣高频SQL50题之1084. 销售分析 III【简单】

传送门&#xff1a;1084. 销售分析 III 题目 表&#xff1a; Product --------------------- | Column Name | Type | --------------------- | product_id | int | | product_name | varchar | | unit_price | int | --------------------- product_id 是该表的主键&#x…
阅读更多...
Kafka入门指南：从零开始掌握分布式消息队列

Kafka入门指南：从零开始掌握分布式消息队列

为什么要有消息队列 生活中有这样的场景快递员将包裹送给买家。 我记得在小时候&#xff0c;收快递是需要快递员电话联系上门时间的。这非常不方便&#xff0c;一方面快递员手中可能有多个包裹&#xff0c;另一方面买家可能在上班时间抽不出身。 后来有了驿站&#xff0c;快递员…
阅读更多...
基于Matlab图像处理的瓶子自动检测与质量评估系统

基于Matlab图像处理的瓶子自动检测与质量评估系统

本文提出了一种基于图像处理的瓶子缺陷检测系统&#xff0c;旨在通过图像分析自动识别和检测瓶子在生产过程中可能出现的缺陷。系统首先通过图像预处理技术&#xff0c;包括灰度转换、二值化处理、噪声去除等步骤&#xff0c;将原始图像转换为适合分析的格式。然后&#xff0c;…
阅读更多...
【Pandas】pandas Index objects Index.name

【Pandas】pandas Index objects Index.name

Pandas2.2 Index objects Properties方法描述Index.values返回 Index 对象的值&#xff0c;通常是一个 NumPy 数组Index.is_monotonic_increasing用于检查索引的元素是否 单调递增Index.is_monotonic_decreasing用于判断索引的值是否 单调递减Index.is_unique用于检查索引中的标…
阅读更多...
JDBC教程,2025版最新讲解.超详细入门教程

JDBC教程,2025版最新讲解.超详细入门教程

以下内容全面详尽地梳理了 JDBC &#xff08;Java Database Connectivity&#xff09;的核心知识点&#xff0c;并在关键环节配以示例代码。若要快速定位&#xff0c;可先查看下方结构&#xff1a; JDBC 概览驱动加载与注册获取数据库连接执行 SQL&#xff08;Statement、Prepa…
阅读更多...
PyTorch中nn.Module详解和综合代码示例

PyTorch中nn.Module详解和综合代码示例

在 PyTorch 中&#xff0c;nn.Module 是神经网络中最核心的基类&#xff0c;用于构建所有模型。理解并熟练使用 nn.Module 是掌握 PyTorch 的关键。一、什么是 nn.Module nn.Module 是 PyTorch 中所有神经网络模块的基类。可以把它看作是“神经网络的容器”&#xff0c;它封装了…
阅读更多...
深入解析三大Web安全威胁：文件上传漏洞、SQL注入漏洞与WebShell

深入解析三大Web安全威胁：文件上传漏洞、SQL注入漏洞与WebShell

文章目录文件上传漏洞SQL注入漏洞WebShell三者的核心关联&#xff1a;攻击链闭环文件上传漏洞 文件上传漏洞&#xff08;File Upload Vulnerability&#xff09; 当Web应用允许用户上传文件但未实施充分的安全验证时&#xff0c;攻击者可上传恶意文件&#xff08;如WebShell、…
阅读更多...
最新文章

Copyright @ 2022~2023