简介面向Java网络编程学习者、毕业设计开发者以及远程运维场景这一基于C/S架构的远程监控系统实现包提供了可直接运行的源代码和完整Word版论文。系统通过Java Socket建立主控端与被控端的通信通道运用Robot类完成屏幕截取与鼠标键盘事件模拟实现了连续获屏、文件上传下载、任意DOS命令执行、远程关机重启等功能适合机房集中管理、实验教学或作为课程设计、毕业设计的蓝本。压缩包共78个文件主体为30个Java源文件与41个class编译文件另含1篇论文文档和Eclipse工程配置文件体积仅1.56MB结构紧凑便于学习。已有1039人浏览学习。配套论文从需求分析、总体设计到编码测试严格遵循软件工程流程代码对Socket通信、多线程、Robot自动化等关键模块均有清晰实现可直接导入Eclipse运行调试也可结合Word文档快速理解系统架构与核心算法便于二次开发和功能扩展。1. 基于 JAVA C/S 远程监控系统软件的源码包这东西能不能直接跑起来这套基于 JAVA C/S 远程监控系统软件的源代码包是我见过比较典型的 Java 课程设计/毕业设计资源一个 Eclipse 工程配一篇 WORD 论文代码里塞了二十多个 Java 文件。功能看着不少——屏幕连续截取、文件上传下载、鼠标键盘模拟、远程执行 DOS 命令、远程关机重启甚至被监控端还做了自启动和隐藏窗口。对正在做 Java 网络编程课设、或者想拿 Socket Robot 练手的人来说它正好踩在“能看懂”和“有东西可改”的中间地带对已经工作的人它更像一面镜子能让你看到早期 Java GUI 项目在协议设计上的各种粗糙。我建议你抱着“拆项目”的心态下载而不是“装好就能当正规远控用”。下面我按自己复现过同类项目的经验从原理、跑通、踩坑到改造一层层说清楚。2. 把系统拆开Socket 控制通道、Robot 截屏和文件传输怎么协作这套代码最迷惑人的地方是命名不统一有Client.java、ClientMessageShow.java、ClientStatus.java这种像客户端的又有ConnectClientFrame.java、MainFrame.java这种像界面的。一开始很容易被绕进去。我建议先别陷进类名而是抓两条通信链路一条是 UDP 命令通道一条是 TCP 数据通道。理解了这两条通道整份代码的骨架就出来了。2.1 命令通道UDP 只负责“告诉对方开哪个门”论文里写得很清楚被监控端启动后先打开指定的 UDP 端口等待命令命令格式是ordername:port。也就是说主控端先把自己的 TCP 端口准备好然后通过 UDP 报文告诉被控端“我要看屏幕你连我 8001 端口”被控端收到后再主动向主控端发起 TCP 连接。这里有一个反直觉的点既然最终要传屏幕数据为什么不直接用一条 TCP 长连接把命令和数据一起传因为这套设计把“命令分发”和“数据传输”拆开了。UDP 报文短、开销小而且不需要保持连接状态主控端只要知道被控端的 IP发一条报文就能触发它回连。真正费带宽的屏幕图像、文件内容全部走独立 TCP 通道通道用完就关互不阻塞。// 被监控端启动后先开一个 UDP 命令端口只做命令分发 DatagramSocket cmdSocket new DatagramSocket(CMD_PORT); byte[] buf new byte[256]; while (true) { DatagramPacket packet new DatagramPacket(buf, buf.length); cmdSocket.receive(packet); // 阻塞等待命令 String order new String(packet.getData(), 0, packet.getLength()); String[] parts order.split(:); // 格式 ordername:port if (parts.length 2) { dispatch(parts[0], Integer.parseInt(parts[1])); } }这段逻辑在源码里分布在ClientOrderReceiver.java、SOrderExcute.java和tools.java里我把它压缩成了最核心的分发循环。dispatch的作用是让被控端根据命令名去选择处理线程screen就启动截屏发送线程file就启动文件传输线程dos就执行 DOS 命令并把回显发回去。参数上要注意三点一是 UDP 端口建议选 1024 以上的空闲端口普通用户在 Windows 和 Linux 下没权限绑定 1 到 1024 的端口二是命令分隔符必须是英文冒号写成中文冒号或空格都会导致split出来只有一段直接走不到dispatch三是整个包代码是按 Windows 环境写的命令名大小写不要随意改dos和DOS会变成两个不同的命令容易被忽略。这个 UDP 命令通道也有一个明显缺点没有确认机制。主控端发出去就算了如果报文在网络里丢了界面就一直卡在“等待连接”不会自动重发。我见过很多人在这个项目上翻车点了按钮没反应其实不是代码跑不起来而是 UDP 丢包后没有超时重试。这个坑到后面避坑章节我会再展开。2.2 屏幕流Robot 截屏 JPEG 帧压缩 独立线程屏幕监控是整套系统的核心卖点。它的实现思路不复杂被控端用java.awt.Robot每隔一段时间抓一次全屏把图像压缩成 JPEG再通过 TCP 发送给主控端主控端收到后在画布上显示这张位图。论文里说“时间间隔短一点就可以获得连续屏幕变化”实际上就是在SendImageThread.java和GetImageThread.java这两个线程之间控制频率。// 发送屏幕线程每 interval 毫秒抓一次全屏压缩成 JPEG 发出 public class SendImageThread extends Thread { private Socket socket; private int interval; // 截屏间隔单位 ms public void run() { Robot robot new Robot(); Rectangle screenRect new Rectangle( Toolkit.getDefaultToolkit().getScreenSize()); while (!isInterrupted()) { BufferedImage image robot.createScreenCapture(screenRect); ImageIO.write(image, jpg, socket.getOutputStream()); sleep(interval); } } }这段代码是给“理解思路”用的不是说源码里一定长这样。但核心点是一致的Robot.createScreenCapture抓取当前桌面ImageIO.write压缩成 JPEG。interval是控制流畅度最关键的一个参数。我实测下来100ms 的间隔在 1366x768 分辨率下 CPU 占用会明显升高而且截图和 JPEG 压缩本身就要几十毫秒间隔设太短反而会让线程排队200ms 到 500ms 是比较稳的区间肉眼看起来已经有“连续变化”的效果了。这里必须提醒一句ImageIO.write直接往socket.getOutputStream()写图片接收端很难判断一帧图像在哪里结束。正规做法是先写 4 个字节的帧长度再写图片字节这套源码在实验和课设场景下能跑是因为接收端用了一个约定好的缓冲大小去读。但如果你想把屏幕帧率提上去不解决帧边界问题图像就会出现错位、花屏甚至把下一帧的控制数据当成图片数据解析。屏幕传送还有一个常见的环境问题Robot只能抓取当前有桌面会话的屏幕。如果被控端锁屏了、切换了用户、或者在远程桌面断开的状态下抓到的往往是黑屏。这个不是 Java Bug而是操作系统对桌面会话的隔离机制后面避坑章节会再讲。2.3 文件与控制FileupLoad、FiledownDialog 与 DOSExcuter 的协作文件上传下载用的还是老套路控制命令走 UDP实际文件走一个新的 TCP 连接。主控端要下载被控端某个文件时会先弹一个FiledownDialog让用户选保存位置然后开一个 TCP 端口等待被控端把文件推过来。上传则是反方向被控端把文件内容发到主控端指定的端口。// 发送文件前先写文件名和长度再写字节伪代码 DataOutputStream out new DataOutputStream(socket.getOutputStream()); out.writeUTF(fileName); out.writeLong(file.length()); byte[] buf new byte[8192]; while ((n in.read(buf)) ! -1) { out.write(buf, 0, n); } out.flush();这段代码的要害是writeUTF和writeLong的顺序。writeUTF会先写两个字节的 UTF-8 长度然后写字符串内容接收端必须用对应的readUTF读取否则字节流就错位了。writeLong写 8 字节文件长度作用是让接收端知道要读多少字节才算完避免一端还在读文件、另一端的后续数据已经挤到同一个流里。我还在文件列表里看到了CStoreFileThread.java和FileupLoad.class说明这套源码对文件传输做了独立线程处理。但从类名也能看出它没有做断点续传也没有校验机制。传一半断线文件就废了。对于课程设计来说这些都可以接受如果真想当工具用至少要加 CRC32 校验这个我在最后一章会给出具体做法。DOS 命令执行相对独立。DosOrderInUI.java是输入界面DOSExcuter.java负责在目标机器上启动进程并抓取回显。// 执行 DOS 命令并读取输出把结果发回主控端 Process process Runtime.getRuntime().exec(cmd /c command); BufferedReader reader new BufferedReader( new InputStreamReader(process.getInputStream()));这里最容易被忽略的参数是cmd /c。/c表示执行完命令后关闭窗口如果去掉它Windows 会弹出一个新的命令行窗口破坏被监控端隐藏运行的设计。另外命令里的管道符和特殊字符要注意转义如果通过 Java 字符串拼命令用户输入或|时可能会被 Windows 解释成多条命令安全上是个隐患。远程关机和重启都是通过命令通道发的比如shutdown -s -t 0测试前一定想清楚目标机器上有没有正在跑的东西。2.4 关键文件对照表把源码包里的文件按功能线整理一下方便你导入工程后对照阅读。功能线文件说明主控端界面MainFrame.java主窗口按钮和画布都在这边被控端入口Client.java启动被控端初始化 UDP 命令端口命令分发ClientOrderReceiver.java接收 UDP 报文并分发指令屏幕截取SendImageThread.java被控端抓屏并发送屏幕显示GetImageThread.java主控端接收并显示屏幕图像鼠标键盘模拟MouseOnPanel.java在画布上采集事件并发送坐标文件上传FileupLoad被控端向主控端推文件文件下载FiledownDialog.java主控端接收文件的对话框DOS 执行DosOrderInUI.java、DOSExcuter.java命令输入和执行自启动autostart.java被控端开机自启这张表不是源码包里的说明文档是我按类名和论文描述整理的。实际看代码时会发现COrderHandle.java、SOrderExcute.java、OrderMap.java这些类也在做命令映射命名比较乱但这张表至少能帮你快速定位到每个功能入口。3. 在 Eclipse 里把它跑起来导入工程、改 IP 端口和过时的 JDK 问题拿到这个 zip 后很多人的第一反应是双击 eclipse 导入然后被一堆红叉劝退。原因很简单工程文件.project和.classpath里指定的编译器级别还是 1.5而现在机器上普遍是 JDK 8 以后有些甚至已经是 JDK 17、21。这不是源码本身的事是工程配置和现代 Eclipse 版本之间的摩擦。3.1 把工程导入工作区并处理编译级别先把 zip 解压到一个没有中文和空格的路径比如D:\workspace\javamonitor。然后打开 EclipseFile - Import - General - Existing Projects into Workspace选择解压目录Eclipse 会自动识别.project文件。如果你的 Eclipse 版本比较新它会提示项目需要修改编译级别如果没提示导入后项目会直接红叉。# 建议先在命令行确认当前默认 JDK 版本 java -version # Eclipse 里用的 JRE 不一定和命令行一致单独看这里 # Window - Preferences - Java - Installed JREs我建议在 Eclipse 里直接添加一个 JDK 8并把项目设为用 JDK 8 编译。原因有两个一是这份源码的年代和 JDK 8 兼容性最好二是 JDK 8 是目前还在广泛使用的版本遇到问题比较容易搜到答案。如果你只有 JDK 17也可以强行把Java Compiler的Compiler compliance level改成 1.8但个别用到内部 API 的老代码可能要改。# 导入完成后删除工程 bin 目录里附带的 .class 文件 # 选中工程 - Build - Clean这一步很多人忽略。源码包把.class和.java混在一起放了如果不清理Eclipse 可能用的是旧的编译产物你改了.java文件后界面行为不变会让人误以为代码没生效。3.2 最关键的改动Parameter.java 里的 IP 和端口接下来要改的参数基本都集中在Parameter.java里。源码里可能还有Client.java里的常量但大部分情况下公共配置放在Parameter.java是更合理的习惯。我一般会把网络配置拆成下面这样// Parameter.java公共配置 public class Parameter { public static String SERVER_IP 192.168.1.100; // 主控端 IP被控端要能访问到 public static int UDP_PORT 9999; // 被控端监听的 UDP 命令端口 public static int TCP_START 8000; // 主控端数据端口起始值 }这里的逻辑要理清楚SERVER_IP是主控端机器的 IP不是被控端 IP。因为整个流程是被控端收到 UDP 命令后主动去向SERVER_IP发起 TCP 回连主控端相当于服务器。UDP_PORT是被控端启动时绑定的端口主控端发命令要发到这个端口。TCP_START是主控端监听数据连接的起始端口每开一类数据通道就递增一个端口避免传文件和传屏幕抢同一个端口。单机测试时SERVER_IP填127.0.0.1就行。但要注意被控端如果绑定了0.0.0.0地址主控端也在同一台机器UDP 和 TCP 端口能同时访问如果是两台机器测试先把 Windows 防火墙关掉或者给java.exe添加专用网络放行否则回连 TCP 端口会被拦。3.3 先单机跑通启动顺序是有讲究的这个项目不像普通 C/S 程序那样先启动服务器再启动客户端就行因为它的命令通道和数据通道是反向的。正确顺序是先启动主控端再启动被控端。# 第一步启动主控端界面 java -cp bin MainFrame # 第二步另开一个终端启动被控端 java -cp bin Client被控端启动后默认没有任何可见界面这是论文里明确写的需求“被监控端自动隐藏运行”。所以你启动Client后如果什么都没看到不代表它没跑起来反而说明它正常工作了。想看它到底有没有监听 UDP 端口可以用netstat验证# Windows 下查看 9999 端口是否被监听 netstat -ano | findstr 9999如果端口没有监听说明Client启动时抛了异常。常见原因是端口被占用或者autostart.java里的自启动逻辑抢先执行导致进程异常退出。把autostart.java从构建路径排除掉可以减少很多干扰。主控端界面打开后填入被控端 IP点击连接之类的按钮。主控端先把命令封装成ordername:port格式发到被控端的 UDP 端口然后等待被控端回连。如果一切正常画布上会出现被控端桌面屏幕上鼠标动一下被控端鼠标也会跟着动。3.4 功能自测清单跑通第一遍后建议用下面这张表逐项验收而不是只盯着屏幕画面看功能操作预期结果屏幕监控主控端点击连接远程屏幕画布出现被控端桌面刷新间隔符合设定值鼠标控制在画布上移动鼠标并点击被控端鼠标跟随移动点击生效键盘控制在画布聚焦时按键盘被控端收到按键事件文件下载主控端发起下载被控端某个文件文件保存到本地文件名和大小一致文件上传主控端选择本地文件上传被控端对应目录出现该文件DOS 命令输入ipconfig /all主控端界面显示完整网络配置远程关机输入shutdown /s /t 5被控端 5 秒后关机提个醒远程关机和重启不要在一个有重要任务的机器上测试。我一般用虚拟机当被控端或者找一台闲置电脑专门做实验。不信邪的话你会在导师/同事面前表演“电脑突然关机”的尴尬场面。3.5 源码里没有写但你应该知道的运行边界这套源码的运行边界很清晰只适合局域网或同一台机器测试不适合公网部署。原因有两个。第一UDP 命令通道没有加密和认证任何人都可以向被控端发命令第二TCP 数据通道用的是ServerSocket被动监听跨公网需要做端口映射或反向代理而且代码里没有处理 NAT 穿透。所以如果你看到有人把它包装成“远程控制软件”卖基本就是在耗 Git 上那些更成熟项目的名气。用的时候还要注意杀毒软件。被控端自动隐藏、自启动、监听端口、模拟鼠标键盘这些行为叠加在一起Windows Defender 和一些安全软件很容易把Client判定为恶意程序。这不是源码有问题是行为特征太像远控木马了。我自己的习惯是在虚拟机里复现或者把工程目录加入杀毒软件白名单避免它把编译产物直接隔离掉。4. 避坑与排查黑屏、闪断、传一半五个翻车现场这一章是我想重点写的。项目本身不大但我见过太多人在同样的地方翻车。下面这几条是复现这个项目时最高频的问题每条都按“现象、原因、解决”写清楚。4.1 被控端启动后“什么都没有”连接也没反应现象双击或命令行启动Client后屏幕上没有任何窗口主控端也连不上。原因被控端设计为隐藏运行它没有主界面是正常的。但如果连 UDP 端口都没监听说明进程没有正常起来或者启动后被autostart.java里的自启动逻辑带偏了。还有一个容易被忽略的点杀毒软件把Client当成木马隔离了进程根本没存活。解决先用netstat -ano | findstr 9999确认端口在不在。进程没起来的话把autostart.java从构建路径排除再在命令行用java -cp bin Client启动这样异常堆栈会直接打到控制台。如果进程被隔离查看 Windows Defender 的威胁历史记录把工程目录添加为排除项重新编译再跑。4.2 主控端点了连接界面卡住然后连接被重置现象UDP 命令看起来发出去了被控端也活着但 TCP 回连瞬间失败主控端报connection reset或一直转圈。原因最常见的是防火墙拦截了被控端向主控端发起的入站连接。Windows 防火墙把网络分成“专用”和“公用”如果主控端机器当前网络配置文件是“公用”默认会拦掉java.exe的入站连接。解决在主控端机器上给java.exe添加防火墙放行规则并允许专用和公用网络如果还不行把两台机器调整到同一个网段路由器 AP 隔离关掉。手工验证可以用telnet从被控端连主控端的 TCP 端口telnet 主控端IP 8000能通说明端口层面没问题再查应用代码。4.3 屏幕画面一直黑屏但被控端明明在正常使用现象主控端画布能显示画面但是全黑或者一开始正常过一会儿变黑。原因Robot只能抓取有桌面会话的屏幕。被控端如果处于锁屏状态、切换了用户、或者通过远程桌面连接且会话断开操作系统的桌面会话就不可见了createScreenCapture抓到的就是黑屏。解决测试时保持被控端处于登录后的桌面状态不要锁屏。用远程桌面测试时被控端必须是在物理控制台登录的状态。如果是 Windows 虚拟机不要最小化 VM 窗口因为部分虚拟机的桌面会话会随前台窗口变化。4.4 鼠标乱跳点击位置不对现象在主控端画布上点左边被控端鼠标跑到右边点上面鼠标跑到下面。原因这是典型的坐标换算问题。主控端的画布显示的是被控端桌面的缩放图画布大小可能和被控端真实分辨率不一致。MouseOnPanel采集到的是画布上的坐标如果没有按比例换算成被控端真实屏幕坐标直接发过去肯定会偏移。解决发送鼠标事件前做一次缩放换算。假设真实分辨率为realW x realH画布显示大小为panelW x panelH那么发送坐标应为int targetX (int) (event.getX() * (realW / (double) panelW)); int targetY (int) (event.getY() * (realH / (double) panelH));另外Windows 10 以后还有 DPI 缩放问题。如果主控端显示缩放是 125% 或 150%Java GUI 拿到的坐标和系统真实坐标之间会产生额外偏差。最简单的办法是把主控端程序的 DPI 感知打开或者让显示比例保持 100%。4.5 小文件传输正常大文件传到一半卡死现象几百 KB 的文件没问题几十 MB 的文件传到约 90% 就卡住最后超时。原因底层原因是文件传输没有按固定长度读取完或者传输线程和界面刷新线程互相阻塞。很多老代码在接收文件时用while ((n in.read(buf)) ! -1)循环但发送端把socket关了之后接收端要等缓冲区数据全读完才能退出如果发送端没关就永远等不到-1。解决发送前先写文件长度接收端循环读满这个长度就结束不要依赖-1判断。传输操作必须放在独立线程里不能在 Swing 的EventQueue线程里做网络读取否则界面会冻结。还有一个小经验文件传输和数据通道不要乱共用一个ObjectOutputStream因为对象流的头和缓冲机制会让字节边界变得不可控。4.6 新 JDK 编译报错IllegalAccessError 或找不到 java.awt.Robot现象在 JDK 9 以上的 Eclipse 里编译某些类报IllegalAccessError或者直接提示无法访问com.sun.*相关包。原因这份源码的年代是 JDK 1.5那时候很多代码会直接使用内部 API比如com.sun.image.codec.jpeg.JPEGCodec。JDK 9 开始模块化内部 API 默认不开放老代码就直接编译不过。解决最省事的方案是装一个 JDK 8在 Eclipse 的Installed JREs里加进来并把工程切到 JDK 8。如果你必须用新 JDK搜索代码里所有import com.sun.*把 JPEG 编码改成ImageIO标准 API。这个工程里的SendImageThread.java和tools.java是重点排查对象。5. 把它改成能用的远程助手自适应帧率、文件校验和验收清单当你把原始项目跑通下一步自然是改造成自己顺手的小工具。我不想再重复“加一个登录框”这种大而全的建议给你几个能立刻写进去的小改动都是在原代码上动小手术就能完成的。5.1 让“连续屏幕”真正连续自适应截屏间隔原代码用固定sleep(interval)控制抓屏频率间隔短了 CPU 高间隔长了画面不连续。我习惯改成动态间隔根据上一帧实际耗时来决定下一帧等待时间。long start System.currentTimeMillis(); sendFrame(); // 发送一帧 JPEG long cost System.currentTimeMillis() - start; long sleep Math.max(50, Math.min(500, cost * 2)); // 动态间隔 Thread.sleep(sleep);这样做的思路是上一帧耗时越长说明网络或压缩是瓶颈下一帧就多等一会避免线程堆积上一帧很快就适当缩短间隔提高流畅度。上下限都用Math夹住防止个别慢速网络把间隔拉得过大也防止 CPU 被无脑打满。如果再激进一点可以加一个“丢帧”逻辑上一帧还没发完当前帧直接丢弃保证发送线程永远不会积压。5.2 给文件传输加上长度头和 CRC32 校验原始文件传输坑在“不知道读多少算完”。改造方式很简单发送前写文件长度传输完成后写校验值接收端按长度读完再比对 CRC32。try (InputStream in new FileInputStream(file); OutputStream out socket.getOutputStream()) { out.writeLong(file.length()); // 先告诉对方总大小 byte[] buf new byte[8192]; int n; CRC32 crc32 new CRC32(); while ((n in.read(buf)) ! -1) { out.write(buf, 0, n); crc32.update(buf, 0, n); } out.writeLong(crc32.getValue()); // 再告诉对方校验值 }接收端先readLong拿到长度再循环读取直到读满长度最后再readLong拿 CRC32 做比对。这个改动对原代码侵入很小但一下就把“传大文件心里没底”的问题解决了。5.3 验收清单我每次都会强制走过的检查改造完之后不要直接拿给同学或同事用。我自己的习惯是固定走一遍这套检查每次都能挡下不少低级问题检查项操作通过标准单机自测主控端和被控端都在本机屏幕、文件、DOS 命令全部通过局域网测试两台物理机连接非本机情况下鼠标坐标和屏幕帧正常防火墙边界主控端机器的网络配置设为专用回连不被拦截断线重连传输长文件时重启被控端主控端能感知断开不卡死编码一致性文件名为中文上传下载后文件名不乱码这套项目给我的一个最实在的教训是远程控制类程序的坑一半在 Java API 之外在操作系统和网络环境里。从那以后我每次调这类代码都强制先走一遍“关防火墙、确认屏幕没锁、再看端口监听”三分钟能避开八成翻车现场。希望帮到你。本文还有配套的精品资源点击获取