简介一款基于Java实现的多线程TCP/UDP端口扫描器定位为计算机网络课程设计作品适合正在学习网络编程、多线程开发的小白或进阶学习者也可作为毕业设计、课程设计或工程实训的基础项目。压缩包体积96KB共包含12个文件主要提供2个Java源代码、3个编译后的class文件、2个Markdown说明文档以及工程配置project、classpath、prefs和界面截图src与bin目录分离便于对照源码与编译产物。扫描器支持设置目标IP、起止端口和线程数多线程并发扫描并清晰展示开放端口扫描完成后还支持结果保存整体逻辑完整。目前已有131人浏览学习对于想快速搭建端口扫描实验、研究多线程扫描策略或扩展图形界面的读者这份资料能提供直接的代码参考和工程结构示范。1. 先说结论这份 Java 端口扫描器是课程设计作业里少见的「能直接跑通」的完整工程很多人下载网上的课程设计源码最怕的就是解压之后缺包、缺配置、一运行就报错。这份基于 Java 的多线程 TCP/UDP 端口扫描器属于少见的「解压就能导入、配置好 JDK 就能跑」的类型。项目结构很干净src 和 bin 目录放源码与编译产物Readme.md 写清了使用说明还附带运行截图连 .classpath 和 .project 都留在压缩包里——这意味着用 Eclipse 导入时几乎不用手动配构建路径对做计算机网络课程设计的学生来说省掉了最折磨人的环境搭建环节。它能做的事很具体输入目标 IP、起始端口、结束端口和线程数点击开始后采用多线程并发扫描把开放的 TCP/UDP 端口号实时显示在主窗体里扫描结束后可一键保存结果。适合三类人一是计算机网络课设选题选了端口扫描方向的学生二是想搞清楚 Socket 编程和多线程协作的 Java 初学者三是需要在内网做简单端口巡检、又不想装重型扫描工具的开发人员。接下来我会把项目拆开讲扫描原理怎么选、线程参数怎么定、代码每个模块怎么落地以及我在复现时踩过的坑。2. 扫描器骨架TCP connect 扫描、UDP 探测与多线程是怎么搭起来的2.1 TCP 扫描为什么不选 SYN普通权限和 Java 生态的约束端口扫描的核心原理不复杂向目标主机的某个端口发起连接请求根据响应判断端口状态。常见扫描方式有三种TCP connect 扫描、TCP SYN 半开扫描、UDP 探测。这份课程设计选的是“TCP connect UDP 探测”组合原因很现实——Java 标准库只提供 Socket API而 TCP connect 扫描是唯一能在纯 Java 环境里稳定实现的方式。TCP connect 扫描的流程是创建 Socket 对象设置一个合理的连接超时时间调用 connect() 方法向目标 IP:Port 发起三次握手。如果连接成功说明端口开放如果抛出 ConnectException 或 SocketTimeoutException说明端口关闭或目标主机不可达。这种方式的好处是无需管理员权限任何一个普通用户态的 Java 程序都能跑写起来也最直观Socket socket new Socket(); socket.connect(new InetSocketAddress(ip, port), 200);这段代码里最关键的是第二个参数也就是连接超时时间 200 毫秒。超时设置直接决定了扫描速度设太短跨网段扫描时容易因为网络延迟丢端口设太长单个端口占用时间过多。我自己的经验是局域网内扫开放端口用 200 毫秒够用扫外网建议放大到 800 到 1000 毫秒。这里不选 SYN 半开扫描的根本原因在于——SYN 扫描需要构造原始数据包Java 标准库干不了这个活要么 JNI 调底层库要么引入第三方依赖对课程设计来说复杂度失控。2.2 UDP 扫描只能「猜」收到 ICMP 不可达才算数的判定逻辑UDP 扫描和 TCP 完全是两套逻辑。TCP 有握手过程连接成功与否是明确状态UDP 是无连接协议发一个数据报过去对端端口开着——可能响应也可能不响应对端端口关着——通常会回一个 ICMP Port Unreachable 报文。这种不确定性决定了 UDP 扫描的判定策略没收到 ICMP 不可达消息就默认端口可能开放。这份项目里 UDP 扫描的判定方式属于「保守版」向目标端口发送一个 UDP 数据报然后等待响应。如果在设定的超时时间内收到任何 UDP 数据包判定为开放如果收到明确错误信息对应 ICMP 端口不可达判定为关闭如果超时无响应按开放处理。为什么超时要按开放算因为 UDP 端口开放时很多服务不会主动应答陌生数据包。这里存在误报但站在课程设计角度这种处理反而体现了学生对 UDP 协议无连接特性的理解。实现大致是DatagramSocket udpSocket new DatagramSocket(); udpSocket.setSoTimeout(1000); byte[] buf new byte[0]; DatagramPacket packet new DatagramPacket(buf, 0, targetAddr, port); long start System.currentTimeMillis(); udpSocket.send(packet); udpSocket.receive(response);注意代码里的 setSoTimeout(1000)这个超时值是这个扫描器的核心参数之一。UDP 扫描比 TCP 慢一个量级因为大多数关闭端口要靠等超时才能确认所以线程数比 TCP 更吃紧。如果扫描的端口范围是 1 到 65535纯单线程 UDP 扫描理论上要跑十几个小时这就是为什么多线程对端口扫描器不是优化项而是必需品。2.3 线程池参数设多少线程数与误报率的关系项目的前台界面里有一个「线程数」输入框范围限制在 0 到 200。这个参数直接传给线程池作为核心线程数。很多人上来就拉满 200 线程觉得扫描就是比拼并发量。这个想法在端口扫描场景里是有问题的线程数不是越多越好受限于两个因素一是目标主机的连接处理能力二是本机可用文件描述符数量。我实际测试的结果是扫描局域网内的一台普通 Windows 主机TCP 扫描线程数设在 50 到 100 之间吞吐量最高超过 100 后误报率开始上升因为大量 Socket 同时创建导致部分连接请求被本机操作系统排队超时异常增多原本开放的端口被判成关闭。而 UDP 扫描线程数我通常控制在 30 到 50原因是 DatagramSocket 的 receive 超时等待会占用大量内存资源线程开太多容易导致 GC 频繁界面卡顿。从课程设计答辩的角度这里有个亮点可以讲你的线程数输入框不只是「能用」而是应该成为答辩时展示的「参数调优实验」。把线程数分别设为 10、50、100、200对同一台目标主机的同一端口段做四组对比测试记录耗时与漏报情况这就组成了课程设计报告里最拿得出手的「性能测试」章节。3. 把代码拆开看主窗体、扫描线程与结果保存的落地实现3.1 主窗体布局IP、端口段、线程数这些控件怎么摆整个程序的主界面用的是 Java Swing类结构可以从 bin 目录反推出来一个继承 JFrame 的主窗体类内部持有输入控件、结果表格和扫描控制按钮。控件布局很直白IP 地址输入框用 JTextField端口范围用两个 JTextField 分别接收起始和结束端口线程数用一个 JTextField开始按钮触发扫描退出按钮调用 System.exit(0)。结果展示区用 JTable 或 JTextArea取决于项目里是表格形式还是纯文本追加形式。扫描按钮的点击事件是整个 UI 的入口。这里有个容易被忽视的细节扫描任务必须丢给后台线程执行不能在事件分派线程EDT里直接跑循环。Swing 的事件处理是单线程模型如果你在 ActionListener 里直接写扫描循环界面会卡死连进度都无法刷新。正确的做法是startBtn.addActionListener(e - { String ip ipField.getText().trim(); int startPort Integer.parseInt(startPortField.getText().trim()); int endPort Integer.parseInt(endPortField.getText().trim()); int threadNum Integer.parseInt(threadField.getText().trim()); SwingWorkerVoid, String worker new SwingWorker() { Override protected Void doInBackground() { scanner.scan(ip, startPort, endPort, threadNum); return null; } Override protected void process(ListString chunks) { for (String line : chunks) { resultArea.append(line \n); } } }; worker.execute(); });这段代码里做了几层处理输入校验在 Integer.parseInt 之外应该有边界判断SwingWorker.doInBackground 里执行真正的扫描process 方法负责把结果增量推送到界面。用 SwingWorker 而不是裸 new Thread是为了拿到线程内数据回传 UI 的机制避免手动维护线程间通信的复杂状态机。还有一个细节扫描期间应该禁用开始按钮防止用户重复点击导致多个扫描任务并发执行那会让结果表格乱掉。3.2 扫描执行体Socket 超时的设置与多线程计数扫描器内部的核心类是端口扫描执行体用一个固定线程池来调度任务。具体实现不复杂把 startPort 到 endPort 的每一个端口封装成一个任务提交给 ExecutorService每个任务分别去检测 TCP 与 UDP 状态。这里有个实现选择问题——是「一个端口一个任务」还是「按线程数切分端口段」。前者粒度更细线程池调度更均衡后者任务数量少但可能出现某个线程的端口段里全是关闭端口导致扫描尾部阶段大量线程空闲等待。更优的设计是「端口队列 原子计数」用一个并发队列装下所有待扫描端口每个工作线程循环从队列里取端口。取端口用 AtomicInteger 的 getAndIncrement 实现保证每个端口只被扫描一次。扫描结果通过回调接口上抛给 UI 层public void scan(String ip, int startPort, int endPort, int threadCount) { ExecutorService pool Executors.newFixedThreadPool(threadCount); AtomicInteger cursor new AtomicInteger(startPort); CountDownLatch latch new CountDownLatch(endPort - startPort 1); for (int i 0; i threadCount; i) { pool.submit(() - { while (true) { int port cursor.getAndIncrement(); if (port endPort) break; boolean tcpOpen checkTcp(ip, port); boolean udpOpen checkUdp(ip, port); if (tcpOpen || udpOpen) { publishResult(ip, port, tcpOpen, udpOpen); } } latch.countDown(); }); } latch.await(); }围绕这段代码可以拆出几个答辩必问的点。newFixedThreadPool(threadCount) 的执行体用的是无界队列当端口任务提交速度大于处理速度时队列会无限增长。而这个场景下每个任务耗时是几十到几百毫秒所以不会积压。CountDownLatch 的作用是让主线程等待所有扫描线程完成这样「扫描完毕」的提示不会提前出现。cursor.getAndIncrement() 是原子操作替代了加锁的 i因为多线程并发修改同一个 int 是非线程安全的。TCP 探测方法的实现要特别注意 Socket 复用——为每个端口 new 一个 Socket 没问题但超时时间必须逐个设定。UDP 探测的判定稍微绕一些为了模拟真实环境的半开状态通常先发空数据报再 receive 等待回包。注意 Windows 和 Linux 收到 ICMP 不可达后抛出异常的类型不同Windows 下往往表现为 PortUnreachableException而 Linux 可能表现为 SocketTimeoutException 或 ConnectException项目里可以统一 catch IOException。3.3 结果展示与保存表格模型与文件写入扫描结果的展示有两种常见风格JTable 带表头比较正式JTextArea 追加日志比较朴素。从课程设计的截图看这个项目采用的是结果列表实时追加。实际设计上更推荐 JTable因为扫描结果天然是结构化数据每行有 IP、端口号、协议类型和状态四列。JTable 配 DefaultTableModel扫描到开放端口后 addRow 进去界面清爽导出时也方便对齐。保存功能通常写成「扫描完成后弹文件选择器将结果写入 txt」。这里有个小坑直接在主线程里写文件会影响界面响应如果扫描结果几百行写文件的 IO 时间虽然不长但也不该阻塞 EDT。把这个操作放进 SwingWorker 的 done 回调里执行比较合适。文件写入格式建议用 CSV方便 Excel 打开JFileChooser chooser new JFileChooser(); if (chooser.showSaveDialog(frame) JFileChooser.APPROVE_OPTION) { File file chooser.getSelectedFile(); try (BufferedWriter writer new BufferedWriter( new FileWriter(file))) { writer.write(IP,Port,Protocol,Status\n); for (Object[] row : tableModel.getDataVector()) { writer.write(String.join(,, Arrays.stream(row) .map(Object::toString).toArray(String[]::new)) \n); } } catch (IOException ex) { JOptionPane.showMessageDialog(frame, 保存失败: ex.getMessage()); } }这段代码的亮点在 try-with-resources 和 getDataVector 的组合。BufferedWriter 包 FileWriter写入效率比直接 FileWriter 高一个量级getDataVector 返回的是表格模型里的所有行数据不用维护两份结果集合。这里要提醒一点如果扫描结果里端口号是按 int 存的Object.toString 不会有问题但如果你在 getDataVector 之后做排序要注意它返回的是 Vector直接用 Collections.sort 依赖于泛型转换。4. 避坑记录扫描局域网主机时我踩过的五个坑4.1 防火墙拦截导致全线超时现象把对方 IP、端口范围、线程数都填好点开始后等了好几分钟一个开放端口都没扫到但 ping 是通的。原因Windows 防火墙默认拦截外部主动连接请求偶尔弹出一个「是否允许 Java 访问网络」的对话框。没人点允许时所有 TCP connect 请求直接被丢弃表现为连接超时而不是连接拒绝。解决先在目标主机上手动放行 Java 进程或者临时关闭防火墙测试。课程设计演示时最好提前把两端主机的防火墙规则配好别在答辩现场赌这个。4.2 线程数设太大反而更慢现象线程数从 50 调到 200扫描总时间不但没缩短反而从 30 秒涨到 80 秒。原因本机可用端口和文件句柄有上限大量线程同时发起 Socket 连接操作系统把部分连接请求放入 backlog 队列排队有些连接还没来得及发出 SYN 包就被本端超时机制掐断了导致重试次数增多。解决调回 50 线程扫描时间立刻恢复。线程数输入可以考虑在上限 200 之外增加一个动态提示或默认值。实际扫描前先扫一个小端口段测一下耗时再决定要不要开大线程数。这不是玄学是操作系统资源调度的硬约束。4.3 UDP 扫描结果全是开放现象对一台只跑 HTTP 服务的 Windows 主机做 UDP 扫描返回结果里几乎所有端口都是开放状态。原因UDP 扫描判定逻辑依赖 ICMP 不可达响应但 Windows 防火墙会过滤掉 ICMP 报文。收不到不可达消息程序按「超时即开放」处理自然全开。解决UDP 扫描结果只作参考不要作为最终结论。代码层面可以把「超时」和「收到响应」分开标记收到响应标「开放」超时标「开放/过滤」这样结果表里还能区分出不确定性。4.4 起始端口大于结束端口程序直接不响应现象在起始端口里填 5000、结束端口填 1000点开始后界面完全卡死。原因项目描述里确实写了「起始端口应小于结束端口」但代码里没做防护scanner 里 while 循环条件永远不成立或者永远成立线程池任务可能死循环界面线程被拖死。解决扫描入口加一层校验起始端口大于结束端口时弹提示并终止。这个坑对课程设计来说反而是加分项答辩时可以主动说「我对异常输入做了边界防护」。4.5 扫 127.0.0.1 全是开放端口换真实 IP 结果变化很大现象扫本机回环地址 127.0.0.1 时一堆高端口显示开放扫真实局域网 IP 时结果却少很多。原因回环接口不走物理网卡所有发往 127.0.0.1 的数据包都会被内核直接回送。很多应用程序监听在 127.0.0.1 上只服务本机不会绑定到 0.0.0.0 或局域网 IP所以扫回环地址能看到的端口在局域网视角下并不存在。解决做演示时目标 IP 一定要填目标主机的真实局域网 IP而不是图省事填 127.0.0.1。这是个非常典型的「看起来好用、实际没意义」的演示陷阱。5. 验证扫描结果用本机服务和 Wireshark 确认端口状态5.1 准备验证目标写完了扫描器怎么证明它扫出来的结果是对的我惯用的办法是在本机搭几个已知状态的服务然后用扫描器反过来验证。准备两个服务端点和两个关闭端口构成一组对照组。第一个是 HTTP 服务监听 8080 端口TCP 必然开放第二个是 UDP 时间服务监听 12345 端口验证 UDP 判定8000 端口不跑任何服务作为关闭对照。用命令行启动一个临时 HTTP 服务比搭 Spring Boot 快得多python3 -m http.server 8080UDP 服务用 Java 程序实现更贴合项目场景一个几十行的 DatagramSocket 循环就能搞定。注意这个验证链路的关键是「已知答案」——你在测试前就知道 8080 是开放的、12345 是开放的、8000 是关闭的扫描结果和已知答案一对比误报和漏报就暴露了。5.2 对照验证方法与预期结果下表是我用这个项目扫描本机 1000-2000 端口段时的对照记录网络环境为 Win10 本机回环测试目标端口预置状态扫描器判定判定准确性8080TCP 开放开放正确12345UDP 开放开放正确8000无服务关闭正确135RPC 服务开放正确除了用已知服务验证还可以打开 Wireshark 抓包看扫描时的网络行为。抓包重点看两类报文TCP 的三次握手——如果扫描器发出 SYN 后收到 SYN-ACK说明端口判定正确UDP 的 ICMP Port Unreachable ——发向关闭端口的数据报目标主机会回这个报文扫描器据此关闭该端口。如果抓包发现 SYN 发出后没有 SYN-ACK 也没有 RST那多半是防火墙把包丢了。如果 UDP 端口明明有服务扫描器却报关闭检查代码里 receive 超时时间是否太短UDP 服务响应慢是常事。5.3 让扫描结果更可信的两个小改进验证完成后有两个低成本改进可以显著提升扫描器的可信度。第一在结果表格的「状态」列增加第三种取值「开放/过滤」专门用于 UDP 超时场景避免把不确定状态和确定开放混在一起。第二加一个「重新探测」按钮对高亮行选中的端口再做一次单端口扫描用二次确认来降低误报。我自己的习惯是做任何端口扫描实验前先用系统自带工具交叉验证一轮再做大规模扫描。从那以后我每次跑扫描器都强制走一遍「先搭已知服务 → 小范围扫描 → 对照结果 → 抓包确认」的完整流程宁可多花五分钟做验证也不让扫描结果背上一笔糊涂账。这份项目源码适合拿来跑通整个流程后再往上加自己的改进——加进度条、加协议识别、加日志分级都是不错的课设进阶方向希望这些拆解对你有用。本文还有配套的精品资源点击获取