这里有一些对我有用的东西(没有仪器):

我没有在两边使用@OneToOne，而是在关系的相反部分(带有mappedBy的部分)使用@OneToMany。这使得属性成为一个集合(在下面的示例中为List)，但我将其转换为getter中的一个项，使其对客户端透明。

这种设置工作缓慢，也就是说，只有在调用getPrevious()或getNext()时才进行选择—并且每次调用只有一个选择。

表结构:

CREATE TABLE `TB_ISSUE` (
    `ID`            INT(9) NOT NULL AUTO_INCREMENT,
    `NAME`          VARCHAR(255) NULL,
    `PREVIOUS`      DECIMAL(9,2) NULL
    CONSTRAINT `PK_ISSUE` PRIMARY KEY (`ID`)
);
ALTER TABLE `TB_ISSUE` ADD CONSTRAINT `FK_ISSUE_ISSUE_PREVIOUS`
                 FOREIGN KEY (`PREVIOUS`) REFERENCES `TB_ISSUE` (`ID`);

类:

@Entity
@Table(name = "TB_ISSUE") 
public class Issue {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Integer id;

    @Column
    private String name;

    @OneToOne(fetch=FetchType.LAZY)  // one to one, as expected
    @JoinColumn(name="previous")
    private Issue previous;

    // use @OneToMany instead of @OneToOne to "fake" the lazy loading
    @OneToMany(mappedBy="previous", fetch=FetchType.LAZY)
    // notice the type isnt Issue, but a collection (that will have 0 or 1 items)
    private List<Issue> next;

    public Integer getId() { return id; }
    public String getName() { return name; }

    public Issue getPrevious() { return previous; }
    // in the getter, transform the collection into an Issue for the clients
    public Issue getNext() { return next.isEmpty() ? null : next.get(0); }

}

这里有一些对我有用的东西(没有仪器):

我没有在两边使用@OneToOne，而是在关系的相反部分(带有mappedBy的部分)使用@OneToMany。这使得属性成为一个集合(在下面的示例中为List)，但我将其转换为getter中的一个项，使其对客户端透明。

这种设置工作缓慢，也就是说，只有在调用getPrevious()或getNext()时才进行选择—并且每次调用只有一个选择。

表结构:

CREATE TABLE `TB_ISSUE` (
    `ID`            INT(9) NOT NULL AUTO_INCREMENT,
    `NAME`          VARCHAR(255) NULL,
    `PREVIOUS`      DECIMAL(9,2) NULL
    CONSTRAINT `PK_ISSUE` PRIMARY KEY (`ID`)
);
ALTER TABLE `TB_ISSUE` ADD CONSTRAINT `FK_ISSUE_ISSUE_PREVIOUS`
                 FOREIGN KEY (`PREVIOUS`) REFERENCES `TB_ISSUE` (`ID`);

类:

@Entity
@Table(name = "TB_ISSUE") 
public class Issue {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    protected Integer id;

    @Column
    private String name;

    @OneToOne(fetch=FetchType.LAZY)  // one to one, as expected
    @JoinColumn(name="previous")
    private Issue previous;

    // use @OneToMany instead of @OneToOne to "fake" the lazy loading
    @OneToMany(mappedBy="previous", fetch=FetchType.LAZY)
    // notice the type isnt Issue, but a collection (that will have 0 or 1 items)
    private List<Issue> next;

    public Integer getId() { return id; }
    public String getName() { return name; }

    public Issue getPrevious() { return previous; }
    // in the getter, transform the collection into an Issue for the clients
    public Issue getNext() { return next.isEmpty() ? null : next.get(0); }

}

如果关系必须不是双向的，那么@ElementCollection可能比使用惰性的One2Many集合更容易。

如果子实体是只读的，那么可以简单地设置optional=false。 然后确保每个映射实体的使用都是通过查询预加载的。

public class App {
  ...
  @OneToOne(mappedBy = "app", fetch = FetchType.LAZY, optional = false)
  private Attributes additional;

and

String sql = " ... FROM App a LEFT JOIN FETCH a.additional aa ...";

．.． 也许坚持也会有用……

这个问题已经很老了，但是在Hibernate 5.1.10中，有一些新的更好的解决方案。

惰性加载除了@OneToOne关联的父端外都有效。这是因为Hibernate没有其他方法来知道是给这个变量分配一个空值还是一个代理。更多细节可以在本文中找到

您可以激活延迟加载字节码增强 或者，您可以删除父端，并使用上面文章中解释的@MapsId的客户端。通过这种方式，你会发现你并不真正需要父端，因为子端与父端共享相同的id，所以你可以通过知道父端id轻松获取子端 ．

首先，对KLE的答案进行一些澄清:

Unconstrained (nullable) one-to-one association is the only one that can not be proxied without bytecode instrumentation. The reason for this is that owner entity MUST know whether association property should contain a proxy object or NULL and it can't determine that by looking at its base table's columns due to one-to-one normally being mapped via shared PK, so it has to be eagerly fetched anyway making proxy pointless. Here's a more detailed explanation. many-to-one associations (and one-to-many, obviously) do not suffer from this issue. Owner entity can easily check its own FK (and in case of one-to-many, empty collection proxy is created initially and populated on demand), so the association can be lazy. Replacing one-to-one with one-to-many is pretty much never a good idea. You can replace it with unique many-to-one but there are other (possibly better) options.

Rob H.有一个有效的观点，但是您可能无法根据您的模型实现它(例如，如果您的一对一关联是可空的)。

现在，就最初的问题而言

A) @ManyToOne(fetch=FetchType.LAZY)应该可以正常工作。您确定它没有在查询本身中被覆盖吗?可以在HQL中指定连接获取和/或通过Criteria API显式设置获取模式，这将优先于类注释。如果不是这样，你仍然有问题，请发布你的类，查询和结果的SQL进行更多的重点对话。

B) @一对一比较棘手。如果它绝对不是空的，那就用Rob H吧。的建议，并具体说明如下:

@OneToOne(optional = false, fetch = FetchType.LAZY)

否则，如果你可以改变你的数据库(添加一个外键列到所有者表)，这样做，并将其映射为“joined”:

@OneToOne(fetch = FetchType.LAZY)
@JoinColumn(name="other_entity_fk")
public OtherEntity getOther()

在OtherEntity中:

@OneToOne(mappedBy = "other")
public OwnerEntity getOwner()

如果您不能这样做(并且不能接受快速抓取)，字节码插装就是惟一的选择。然而，我不得不同意CPerkins的观点——如果你有80个!!由于渴望一对一的联系，你有更大的问题:-)