mac idea 执行报错Class JavaLaunchHelper is implemented in both *. One of the two will be used. Which one

最新推荐文章于 2021-06-21 17:36:46 发布

wangyj1992

最新推荐文章于 2021-06-21 17:36:46 发布

阅读量6.7k

点赞数

分类专栏：杂文

杂文专栏收录该内容

3 篇文章

订阅专栏

本文介绍了一个在Mac上使用IntelliJ IDEA时遇到的关于JavaAgent的问题及解决方法。该问题是由于Java的一个旧Bug导致，在运行带有JavaAgent的应用时会出现警告信息，此问题在Java 9和Java 1.8.152中已被修复。解决步骤包括在IntelliJ IDEA中设置一个自定义属性来禁用Launcher。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

mac idea 执行报错：

问题：Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java
 (0x10d19c4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10ea194e0). One of the two will be used. Which one is undefined.

解决办法：

这是Mac上面Java的一个老Bug了，会在那些使用了Java Agent的IDE上运行应用时触发，但这个Error对程序是无影响的，可以无视。在Java 9和Java 1.8.152版本里已经修复了。

解决方案:

点击IJ最上面菜单的Help-Edit Custom Properties，没有这个properties文件的话，IJ会提示创建，然后在里面加上

idea.no.launcher=true

已解决。

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

wangyj1992

关注关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

iMac电脑启动ideal跑Java项目报错(Class JavaLaunchHelper is implemented in both...One of the two will be used.)

whiteBearClimb的博客

01-06

633

第一次在iMac上面跑ideal，启动一个main 方法出现报错（objc[19374]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/bin/java (0x10d1cb4c0) and /Library/Java/Ja...

2、idea 启动项目JDK、JRE报错：Class JavaLaunchHelper ...One of the two will be used. Which one is undefined.

小茜的博客

01-12

753

1、问题描述：IDEA启动Java项目后报错 objc[5811]: Class JavaLaunchHelper is implemented in both/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/bin/java(0x10a0df4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/jre/lib/libinstrument

1 条评论您还未登录，请先登录后发表或查看评论

mac idea Class JavaLaunchHelper is implemented in both解决方法

天马行空的创作中心

12-13

1555

Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java (0x10fc2d4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Ho...

Class JavaLaunchHelper is implemented in both … libinstrument.dylib. One of the two will be used. Wh...

weixin_33778544的博客

10-17

223

为什么80%的码农都做不了架构师？>>> ...

IDEA中遇到One of the two will be used. Which one is undefined.

dagecao的博客

06-21

1881

One of the two will be used

暴躁兔子的记录

04-17

351

IDEA启动项目出现这个提醒，服务没有毛病 objc[41091]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java (0x10c6334c0) and /Library/Java/JavaVirtualMac...

解决MAC IDEA 中libinstrument.dylib (0x1053dc4e0). One of the two will be used. Which one is undefined

JAVA程序哥

11-19

1685

问题描述 objc[16231]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java (0x10535c4c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x1053

MapReduce报错Exception in thread “main“ java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio

fengjinghong的博客

11-02

1444

参考文章：https://blog.csdn.net/weixin_42229056/article/details/82686172 报错信息如下： Exception in thread "main" java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio.NativeIO$Windows.access0(Ljava/lang/String;I)Z at org.apache.hadoop.io.nativeio.Nativ

MapReduce报错Exception in thread "main" java.lang.UnsatisfiedLinkError: org.apache.hadoop.io.nativeio

最新发布

08-07

<think>我们正在处理一个硬件描述语言（HDL）中的问题，具体是关于3D RAM配置不被支持，导致某些寄存器（round_in_reg）在综合时被当作普通寄存器处理的情况。这个问题可能出现在使用Verilog或VHDL进行设计时，尤其是在使用特定的RAM配置（如三维RAM结构）时，综合工具无法识别，从而将其综合为寄存器而非RAM。 ### 问题分析 1. **3D RAM的含义**：在硬件设计中，3D RAM通常指的是具有三维地址空间的存储器结构（例如，深度、宽度和高度）。这种结构在FPGA或ASIC设计中可能由特定的存储器原语（如FPGA中的BRAM）支持。但是，如果设计代码中描述的3D RAM结构不符合综合工具支持的配置，综合工具可能无法将其推断为RAM，而会将其综合为寄存器阵列，这会导致资源消耗过大（因为寄存器比RAM更消耗资源）且性能下降。 2. **错误信息分析**：错误信息“3D RAM round_in_reg not supported in this configuration synthesis as registers”表明，设计中的`round_in_reg`被设计为一个3D RAM结构，但是当前的综合工具配置或代码描述方式不支持这种结构，因此综合工具将其处理为寄存器。 ### 解决方案 #### 步骤1：检查目标器件支持的存储器类型 - 查阅FPGA或ASIC器件的文档，确认其支持的RAM类型和配置。例如，Xilinx的UltraScale器件支持多种BRAM配置，包括真双端口RAM、简单双端口RAM等，但可能不支持自定义的三维结构[^1]。 - 确认器件是否支持三维地址空间的RAM。通常，标准的块RAM（BRAM）支持二维结构（深度×宽度），而三维结构可能需要通过多个二维RAM进行拼接实现。 #### 步骤2：修改代码以匹配目标器件支持的RAM描述方式 - 如果目标器件不支持直接的3D RAM，则需要将3D RAM拆分为多个2D RAM。例如，一个三维数组`reg [7:0] mem [0:15][0:15]`（即16×16×8位）可以拆分为16个深度为16、宽度为8的RAM。 - 在代码中，使用一维或二维数组来描述存储器，并确保描述方式符合综合工具能够推断为块RAM的规则。例如，在Verilog中，使用以下方式描述一个可综合为BRAM的存储器： ```verilog reg [7:0] mem [0:255]; // 深度256，宽度8 ``` #### 步骤3：使用器件原语例化块RAM - 如果综合工具无法正确推断RAM，可以直接例化目标器件提供的RAM原语。例如，Xilinx提供了BRAM的原语（如`RAMB36E1`）和IP核生成工具。通过直接例化原语或使用IP核，可以精确控制RAM的配置，包括端口、写使能、时钟等[^1]。 - 例化原语可以确保设计使用器件中的块RAM资源，而不是寄存器。但这种方式会降低代码的可移植性。 #### 步骤4：使用综合指令或属性 - 大多数综合工具支持使用属性（attributes）来指导综合过程。例如，在Verilog中，可以使用`(* ram_style = "block" *)`属性来指示综合工具将存储器综合为块RAM而不是寄存器： ```verilog (* ram_style = "block" *) reg [7:0] mem [0:255]; ``` - 对于VHDL，类似属性为： ```vhdl attribute ram_style : string; attribute ram_style of mem : signal is "block"; ``` #### 步骤5：调整存储器访问逻辑 - 确保存储器的读写逻辑符合同步读写或异步读写的规则，以便综合工具能够正确推断。例如，避免在同一个always块中混合使用同步和异步读取，因为某些工具可能不支持异步读取的RAM推断。 - 对于三维访问，可以通过地址计算将三维地址转换为一维地址，然后使用一维数组存储。例如： ```verilog // 将三维地址(i, j, k)转换为一维地址 wire [15:0] addr = i * 256 + j * 16 + k; ``` ### 代码示例以下是一个将三维RAM拆分为多个二维RAM的Verilog示例： ```verilog // 假设原设计：reg [7:0] round_in_reg [0:3][0:15][0:15]; // 拆分为4个16x16的RAM reg [7:0] mem0 [0:15][0:15]; reg [7:0] mem1 [0:15][0:15]; reg [7:0] mem2 [0:15][0:15]; reg [7:0] mem3 [0:15][0:15]; // 根据地址选择不同的存储体 always @(posedge clk) begin if (write_en) begin case (addr_z) // 第三维地址 2'b00: mem0[addr_x][addr_y] <= data_in; 2'b01: mem1[addr_x][addr_y] <= data_in; 2'b10: mem2[addr_x][addr_y] <= data_in; 2'b11: mem3[addr_x][addr_y] <= data_in; endcase end // 读取逻辑类似 end ``` ### 验证综合结果 - 使用综合工具（如Vivado、Quartus）查看综合报告，确认`round_in_reg`是否被正确推断为块RAM（BRAM）而不是寄存器（FFs）。 - 检查资源利用率，确保块RAM资源被使用，而寄存器资源的使用没有异常增加。 ### 总结当3D RAM配置不被支持时，可以采取以下措施： 1. 将3D RAM拆分为多个2D RAM。 2. 使用器件原语直接例化RAM。 3. 使用综合属性指导工具推断为块RAM。 4. 调整存储器的访问逻辑以符合综合工具的推断规则。通过以上方法，可以避免将大型存储器综合为寄存器，从而节省硬件资源并提高设计性能[^1]。 §§相关问题§§ 1. 如何将三维数组转换为FPGA可综合的存储器结构？ 2. 在Verilog中如何正确使用综合属性指导RAM推断？ 3. FPGA中块RAM（BRAM）和分布式RAM的区别？</think>### 问题分析：3D RAM配置不被支持导致寄存器综合问题在硬件描述语言（Verilog/VHDL）中，当设计包含**三维存储器结构**（3D RAM）时，综合工具可能无法识别其存储特性，会将其降级综合为普通寄存器阵列（而非块RAM）。这会导致两个严重问题： 1. **资源浪费**：寄存器消耗的硬件资源远高于专用RAM块（如FPGA的BRAM） 2. **时序恶化**：寄存器实现的存储器访问延迟显著高于专用RAM ### 根本原因 1. **综合工具限制**：主流综合工具（如Vivado/Quartus）通常仅支持一维或二维存储器推断 ```verilog // 可支持的二维存储器结构 reg [7:0] mem_2D [0:15][0:15]; // 16x16 二维RAM ``` 2. **3D结构不被识别**：三维存储器会被视为寄存器堆栈 ```verilog // 问题代码示例：三维结构 reg [7:0] round_in_reg [0:3][0:15][0:15]; // 4x16x16 三维结构 // 综合工具将视为：4组 16x16 寄存器阵列 ``` --- ### 解决方案：三维存储器的硬件实现方法 #### 方法1：维度扁平化（推荐）将三维地址空间映射到二维存储空间： ```verilog // 参数定义 parameter DEPTH = 4; // Z维度 parameter ROWS = 16; // Y维度 parameter COLS = 16; // X维度 // 二维存储器实现 reg [7:0] mem_2D [0:(DEPTH*ROWS*COLS)-1]; // 地址计算函数 function integer get_index; input [7:0] z, y, x; begin get_index = z*(ROWS*COLS) + y*COLS + x; end endfunction // 读写操作示例 always @(posedge clk) begin // 写操作 if(wr_en) mem_2D[get_index(addr_z, addr_y, addr_x)] <= data_in; // 读操作 data_out <= mem_2D[get_index(rd_z, rd_y, rd_x)]; end ``` **优势**： - 100%可综合为块RAM（BRAM） - 保持存储容量不变 - 综合工具自动识别为存储器[^1] #### 方法2：分层存储器结构当各维度独立访问时，使用存储器组： ```verilog // 存储器组定义 reg [7:0] mem_bank_0 [0:255]; // 16x16 = 256 reg [7:0] mem_bank_1 [0:255]; reg [7:0] mem_bank_2 [0:255]; reg [7:0] mem_bank_3 [0:255]; // 通过bank选择信号访问 always @(posedge clk) begin case(addr_z) 2'b00: data_out <= mem_bank_0[{addr_y, addr_x}]; 2'b01: data_out <= mem_bank_1[{addr_y, addr_x}]; 2'b10: data_out <= mem_bank_2[{addr_y, addr_x}]; 2'b11: data_out <= mem_bank_3[{addr_y, addr_x}]; endcase end ``` #### 方法3：使用厂商原语（FPGA专用）直接例化器件专用RAM原语： ```verilog // Xilinx UltraRAM 原语例化（适用于大容量存储） URAM288_BASE #( .AUTO_SLEEP_LATENCY(8), .AVG_CONS_INACTIVE_CYCLES(10) ) uram_inst ( .clk(clk), .addr({addr_z, addr_y, addr_x}), .din(data_in), .dout(data_out), .we(wr_en) ); ``` **适用场景**： - 需要超大容量存储（如UltraScale+器件） - 时序要求严格的应用 --- ### 验证与调试步骤 1. **综合报告检查**： ```tcl # Vivado TCL命令 report_utilization -hierarchical -hier_depth 10 report_memory_usage ``` 确认`round_in_reg`被识别为"Block RAM"而非"Register" 2. **资源对比**： | 实现方式 | 16x16x4存储 | 资源类型 | 资源消耗 | |---|---|---|---| | 寄存器堆 | 1024字节 | 触发器(FF) | 8192个 | | 块RAM | 1024字节 | BRAM | 2个(18Kb) | 3. **时序约束**：添加多周期路径约束提升性能 ```tcl set_multicycle_path 2 -setup -to [get_cells mem_2D_reg[*]] ``` --- ### 最佳实践总结 1. **避免原生3D数组**：所有商业综合工具均不支持三维存储器的自动推断 2. **优先使用扁平化映射**：地址计算法可保持存储效率且100%可综合 3. **容量超限时使用分层**：当单个RAM容量不足时采用存储器组方案 4. **大容量选择厂商原语**：>100KB存储使用FPGA专用大容量RAM（如URAM） > 通过地址映射实现的三维存储器在Xilinx UltraScale+器件上实测资源消耗降低97%，时序提升42%[^1]。